Last Comment Bug 646611 - Image corruption with fglrx on yahoo.com
: Image corruption with fglrx on yahoo.com
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: ImageLib (show other bugs)
: unspecified
: x86_64 Linux
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://l.yimg.com/a/i/us/nws/2008/new...
Depends on: 562746
Blocks: 583115
  Show dependency treegraph
 
Reported: 2011-03-30 13:51 PDT by adrian
Modified: 2011-05-30 22:08 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
?


Attachments
The image in question (13.37 KB, image/png)
2011-03-30 13:52 PDT, adrian
no flags Details

Description adrian 2011-03-30 13:51:12 PDT
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.
Comment 1 adrian 2011-03-30 13:52:56 PDT
Created attachment 523104 [details]
The image in question
Comment 2 Boris Zbarsky [:bz] 2011-03-30 18:03:29 PDT
Jeff, can you take a look?

We really need that way to nominate bugs to block next-release, asap....
Comment 3 Siarhei Siamashka 2011-04-02 05:15:36 PDT
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.
Comment 4 adrian 2011-04-03 11:43:09 PDT
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.
Comment 5 Siarhei Siamashka 2011-04-04 01:34:57 PDT
(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.
Comment 6 adrian 2011-04-04 13:44:15 PDT
(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.
Comment 7 adrian 2011-04-04 21:29:41 PDT
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?
Comment 8 Boris Zbarsky [:bz] 2011-04-04 22:25:50 PDT
ccing Karl and Jeff
Comment 9 Siarhei Siamashka 2011-04-15 11:42:51 PDT
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.
Comment 10 christian 2011-04-15 12:39:20 PDT
This doesn't look like it need to resolve this before going to beta for FF5, so tracking -
Comment 11 adrian 2011-04-15 14:49:44 PDT
Ok, so I tried Xephyr like Siarhei asked in comment 9, and the corruption goes away.
Comment 12 Jeff Muizelaar [:jrmuizel] 2011-04-15 15:31:53 PDT
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.
Comment 13 Siarhei Siamashka 2011-04-16 00:27:05 PDT
(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.
Comment 14 Siarhei Siamashka 2011-04-16 00:42:15 PDT
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.
Comment 15 Siarhei Siamashka 2011-04-16 00:46:41 PDT
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.
Comment 16 adrian 2011-05-30 18:17:26 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.