[Bug 35579] Poor performance in Firefox 4

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Mar 26 10:56:46 PDT 2011


--- Comment #29 from Konstantin Svist <fry.kun at gmail.com> 2011-03-26 10:56:46 PDT ---
(In reply to comment #27)
> (In reply to comment #26)
> > There must be something wrong with the driver, after all. That is to say, looks
> > like the proprietary drivers optimize for this somehow
> It's mostly a matter of (lack of) manpower to spend on such workarounds. At
> least in this case, it seems like it should be easy for Firefox / cairo to
> avoid the problem, which will also benefit already deployed X stacks.

I think they don't feel they have to do this since most major drivers are
already optimized for it.
How involved would a fix be? I assume it's probably somewhat harder than
casting a max texture size onto the crazy-sized image...
I'd be interested in helping out if you can tell me where to dig :)

(In reply to comment #28)
> (In reply to comment #26)
> > Does the new generation hardware still have the source image size limits? 
> radeon family - max texture coord
> r1xx-r4xx     - 2k
> r5xx          - 4k
> r6xx-r7xx     - 8k
> evergreen-ni  - 16k
> Other vendors have similar limits for their chips in the same time periods.

Thanks! Should I make a 30k-long test instead of 15k? Then you can try it on an
evergreen card and see how it's still slow :(

Main problem is that  the "design pattern" for web developers is copy/paste
without understanding of the code. And those who don't do that, tend to
optimize for the most common -- D2D/D3D on Windows, fglrx/nvidia on Linux
Same for Firefox/Cairo guys, really - they'd rather call the driver "broken"
and get on with something more fun.

Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the xorg-driver-ati mailing list