646611 - Image corruption with fglrx on yahoo.com

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[adrian]

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]

Attachment: The image in question

Comment 2

[Boris Zbarsky [:bzbarsky]]

Jeff, can you take a look?

We really need that way to nominate bugs to block next-release, asap....

Comment 3

[Siarhei Siamashka]

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]

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]

(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]

(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]

The first bad revision is:
changeset:   48764:1d2eda34572a
user:        Karl Tomlinson <[e-mail]>
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 [:bzbarsky]]

ccing Karl and Jeff

Comment 9

[Siarhei Siamashka]

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

[LegNeato]

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

Comment 11

[adrian]

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

Comment 12

[Jeff Muizelaar [:jrmuizel]]

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]

(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]

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]

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]

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.