User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.2a1pre) Gecko/20110330 Firefox/4.2a1pre Build Identifier: 4.2a1pre (2011-0330) Yahoo uses really large images, and then displays parts of them to speed up page load. However the large images cause image corruption when displayed. The corrupt images are evident all over the yahoo website. Reproducible: Always Steps to Reproduce: a. use a new profile (optional) 1. load the url 2. unscale the image:the corruption is there when scaled, but is hard to see when small. (unscale the image by clicking on it if it is scaled) Actual Results: The image is mostly white with some random block of color. Expected Results: The image should have the icons that yahoo uses in various places on their website. Note a pixman update just landed, perhaps it caused the issue.

Jeff, can you take a look? We really need that way to nominate bugs to block next-release, asap....

Not reproducible for me on amd64 for today's checkout of minefield 4.2a1pre and radeon drivers with "RenderAccel" set to "False". Could it be some problem related to the graphics drivers on your computer? I guess 18×11700 image might be bigger than the maximum texture size supported by your GPU, hitting some kind of corner case.

I did a regression range on this and got Last good nightly: 2010-08-02 First bad nightly: 2010-08-03 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a4d86c3a3494&tochange=4daa2ea5747b However the png is blank for 2010-08-03, not noisy. So I did a regression range on noise vs blank and got Last good(blank) nightly: 2010-09-07 First bad nightly: 2010-09-08 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cf0088ff07f2&tochange=36f5cf6b2d42 re: comment 3 It could be my drivers I use fglrx and not radeon on amd64. However Gimp 2.6, Eye of Gnome, Firefox 3.6 all render the image properly, so it probably is not my drivers.

(In reply to comment #4) > I did a regression range on this and got > Last good nightly: 2010-08-02 First bad nightly: 2010-08-03 Thanks. Could you try to bisect it to a single commit? > re: comment 3 It could be my drivers I use fglrx and not radeon on amd64. > However Gimp 2.6, Eye of Gnome, Firefox 3.6 all render the image properly, so > it probably is not my drivers. They are probably not using RENDER extension in exactly the same way as Firefox 4, so this does not necessarily prove anything. So is this a regression compared to 3.6 and not 4.0? Based on the information you have provided, it seems to me that pixman update which happened after 4.0 is most likely unrelated.

(In reply to comment #5) > (In reply to comment #4) > > I did a regression range on this and got > > Last good nightly: 2010-08-02 First bad nightly: 2010-08-03 > > Thanks. Could you try to bisect it to a single commit? I will try, but it will take me a long time, slow laptop, need to learn the tools etc. If I work on it every day it will take me around a week. I might give up before I finish(INPTWOF). > So is this a regression compared to 3.6 and not 4.0? Based on the information > you have provided, it seems to me that pixman update which happened after 4.0 > is most likely unrelated. Yes, I believe the regression range I did to be accurate. :) However, I did a binary search, which assumes that the bug does not hop in and out of the tree.

The first bad revision is: changeset: 48764:1d2eda34572a user: Karl Tomlinson <karlt+@karlt.net> date: Tue Aug 03 13:26:27 2010 +1200 summary: b=583115 use XCopyArea for operator SOURCE with compatible COLOR_ALPHA surfaces to support simple overlapping self-copies r=jrmuizel I used Hg bisect to find this... What is the next step? should I comment in that bug?

ccing Karl and Jeff

I would also suggest to try some testing with Xephyr. Something like running: $ Xephyr :2 -screen 800x600 And in another terminal: $ DISPLAY=:2 firefox You should also close all the firefox windows before running this test. Because Xephyr uses software rendering, it can help to check whether some issues are hardware acceleration related or not. If the problem disappears when running the browser in Xephyr, that would point to a possible bug in the video driver.

This doesn't look like it need to resolve this before going to beta for FF5, so tracking -

Ok, so I tried Xephyr like Siarhei asked in comment 9, and the corruption goes away.

Siarhei, do you know if Xephyr supports XRender? If it doesn't it could also be a bug in cairo's XRender path, otherwise this looks like a video driver bug.

(In reply to comment #12) > Siarhei, do you know if Xephyr supports XRender? Yes, Xephyr supports a number of extensions, including XRender: http://en.wikipedia.org/wiki/Xephyr This can be also easily verified by running $ DISPLAY=:2 xdpyinfo or $ DISPLAY=:2 rendercheck > If it doesn't it could also be a bug in cairo's XRender path, > otherwise this looks like a video driver bug. How are the bugs in proprietary drivers usually handled? I guess at the very least they need to be reported to the graphics drivers vendor.

This is also some interesting link: https://bugs.freedesktop.org/show_bug.cgi?id=35579 It's about the open source radeon driver, not a proprietary one. But it provides some information about radeon hardware limits and hints why such large images are very problematic to accelerate both fast and correctly.

I guess the only good solution when working with the buggy drivers in firefox is to do client side software rendering and only flush the final pictures to the X server. This is also likely to be avoid severe performance degradation in some corner cases, providing good overall performance.

This was fixed by the nightly 2011-05-28 (still broken on the 27th) Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0cf4fa02c0f2&tochange=1f25c65e9335 My guess would be Bug 562746 (Update cairo to 1.10) fixed it. So resolved fixed now, if I have the designation wrong please fix. Thanks for all your help.