https://bugs.freedesktop.org/show_bug.cgi?id=35579
--- Comment #29 from Konstantin Svist <[email protected]> 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. _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
