Closed Bug 411831 Opened 16 years ago Closed 16 years ago

Images rendered incorrectly when XAA Offscreen Pixmaps are enabled in X and the color depth is 24 bits

Categories

(Core :: Graphics, defect)

All
Linux
defect
Not set
major

Tracking

()

RESOLVED INVALID

People

(Reporter: grfgguvf, Unassigned)

References

()

Details

(Keywords: relnote)

Attachments

(14 files)

118.52 KB, image/png
Details
299.86 KB, image/png
Details
148.20 KB, image/png
Details
152.59 KB, image/png
Details
134.96 KB, image/png
Details
130.51 KB, image/png
Details
274.78 KB, application/x-gzip
Details
3.51 KB, image/gif
Details
5.74 KB, image/gif
Details
247.82 KB, image/png
Details
42.82 KB, image/png
Details
245.98 KB, image/png
Details
13.11 KB, image/png
Details
662 bytes, image/png
Details
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008010314 Fedora/1.9-0.beta2.6.fc9 Firefox/2.0.0.100
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008010314 Fedora/1.9-0.beta2.6.fc9 Firefox/2.0.0.100

See the screenshots. Sorry but Help»Report Broken Web Site... brings up a yellow window with error message in it.

Reproducible: Always

Steps to Reproduce:
1. Go to mugshot.org
2.
3.
It seems to be video-driver dependant: not reproducible with vesa X.org driver (ABI version 4). Screenshots were made using nv X.org driver (ABI version 3)
I've been seeing something very much like this (the first part) for some time on Ubuntu Gutsy (7.10) and Hardy (8.04), using an open source Nvidia graphics driver.

Images (apparently only PNG) often fail to render and sometimes render incorrectly when scaled.

This also affects Liferea on Ubuntu Hardy, which is now embedding Gecko 1.9.

Bug 409345 describes identical symptoms and may be a dupe; bug 413276 sounds similar though I'm not convinced it's related.

My machine has a low memory spec (<400 MB), so I suspect (as a non-developer and general idiot) that bug 402631 may be the culprit.

I'm confirming this bug (since we seem to have three independent accounts) and increasing its severity to major, as this is a major rendering regression over Fx 2 that (for those it affects) makes using Firefox for day-to-day browsing awkward. I'm also requesting blocking-firefox3 for the same reason and to get some attention.

I have screenshots demonstrating scaled images being misrendered, which will follow.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3?
Confusingly, the image itself depicts a misrendering of images; but the image is being rendered correctly. Note, however, that the page icon (a scaled version of the image) is rendered wrongly.
This is the same image as attachment 300345 [details], but scaled to fit within the window. The bottom portion of the previously-visible part of the image shows at the top, and the rest is blacked out.

In some cases (not shown here) the page icon changes when zooming in for the first time. Generally it shows vertical bars of colour (or black and white), then changes to a square of grey (and stays like that). In all cases, it's rendered wrongly.
The Broken Website reporter works for me, so I'm morphing this bug to only cover the image display issues. If you still have problems with it in the latest nightlies (sounds like an XML error), please file a new separate bug.
Summary: Broken site(s): Scaled images not shown at all & Broken site reporter broken → Scaled images rendered incorrectly; some images not shown at all (apparently PNG-, Linux-, & Nvidia-related)
This is not PNG-specific – background GIF images disappear from the BBC homepage beta in Fx 3; screenshots to follow.
Summary: Scaled images rendered incorrectly; some images not shown at all (apparently PNG-, Linux-, & Nvidia-related) → Scaled images rendered incorrectly; some images not shown at all (apparently Linux- & Nvidia-related)
This page renders correctly in Firefox 2 (aside from the black box around the Flash clock).
In Firefox 3, several background images don't appear.

The frames around “Customise homepage”, “Set your location” and “Reset homepage” are absent; these are background images and are GIF (presumably transparent GIF, though I haven't checked).

The arrow to the left of the “News” heading (bottom left of the picture), and the frame around “Edit” to its right are both also gone. (I assume without checking that these are background images.)

So far this bug has been seen affecting background images in PNG and GIF formats; I'm not sure whether it affects fully opaque images.
I have performed some science.

Results:

1: When loaded directly into Firefox, transparent images are not drawn at all, irrespective of whether they are scaled or unscaled.

2: Opaque images are always drawn. They are drawn correctly when unscaled, but wrongly when scaled.

3: Typically, scaled opaque images appear fully black; they sometimes show a portion of the picture in the wrong place (but still within the bounds of the image on the screen).

4: The incorrectly-placed portion appears when redrawing the image at a higher scale factor; as the scale factor approaches 100%, the image gradually moves to occupy its proper position.

5: There was no difference observed between GIF, PNG and JPEG images.

6: For all images, the page icon behaves erratically: it usually shows as vertical bars in some combination of black, white and the OS theme's highlight colour (!); changes when the image is redrawn or another tab is selected; and tends towards a grey square. The icon in the tab is not always the same as the icon in the location bar.

The process used to arrive at the results:

1: Four images were created using the Gimp: a transparent PNG, an opaque PNG, a transparent GIF, an opaque GIF. The opaque images were made using the Gimp's Flatten Image command; they have a red background for clarity. The transparent ones' backgrounds are completely transparent. The images are all somewhat taller than will fit in a maximised Firefox window (900 px), so Firefox will scale them they're loaded.

2: The images were all loaded into the latest trunk build of Firefox (Gecko/2008012904) running on Ubuntu Hardy (pre-release, vintage today). When the images were loaded in, the window was at a small size (to allow me to drag them in from the desktop); the content area was roughly 400 px tall.

3: The window was then maximised so the content area was about 540 px tall. This caused each image to be redrawn at a higher magnification (though still much less than 100%).

4: Screenshots were taken of each image in a maximised browser, scaled and unscaled (zoomed in by clicking). For the opaque images, screenshots were taken at two scale factors (plus unscaled): the original scale when the pictures were loaded (in an unmaximised window), and a larger scale <100% (in a maximised window).

(Some of these screenshots, and the images used to make them, are included in the attachment. I have the complete set if anyone's interested.)

5: A smaller opaque PNG image was made, that would fit inside a maximised window unscaled. This was loaded into a small browser window whose height was then varied (and the image allowed to redraw at various scales) until the image fitted unscaled inside the window.

6: A JPEG image was made, loaded and observed scaled and unscaled.
One more thing: I've also observed background images render as copies of other parts of the screen  (including parts of Gnome's panels, which Firefox shouldn't know about), though this is more difficult to reproduce.
The Broken Website Reporter stated working after an upgrade.

The incorrect rendering of images sounds more and more like an X.org (XSHM?) bug that Firefox exposes. Especially parts of other windows showing up in images. Not only background images, I also get them in animated GIFs.

And we are both using prerelease versions of X.org.
It might be possible that this is indeed some X.org (specifically, "nv" driver?) issue that is only exposed by FF3. However, the interesting bit is that

1. The same issues don't occur on FF2

2. I have seen no issues whatsoever with other applications (and that includes graphic-intensive ones like movie players, image editing, etc.) when using the same X.org and driver.
(In reply to comment #15)
> 2. I have seen no issues whatsoever with other applications (and that includes
> graphic-intensive ones like movie players, image editing, etc.) when using the
> same X.org and driver.
> 

I've seen it in Liferea, but that embeds Gecko 1.9.

I've filed this bug at Ubuntu's Launchpad as https://bugs.launchpad.net/ubuntu/+bug/187680 .
Hmm, might be the shared Gecko 1.9 then.

There is also this older bug on Launchpad:

https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/182038

I can also reproduce with 'vmware' X.org driver (inside VMware Server 2), and the 'nouveau' driver, but the latter shows many more unrelated bugs too.
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → general
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3) Gecko/2008020513 Firefox/3.0b3

This happens for me too, I use the intel 2.2.0 driver and xorg 1.4.0.90 on ArchLinux with XAA acceleration.
Version: unspecified → Trunk
dupe of bug 380115 ?
if you see this, please test if the latest patch in there fixes your issue as well.
Component: General → GFX: Thebes
QA Contact: general → thebes
I can confirm this with Xorg 7.3 and the OSS radeon driver.
I don't know if this is the same bug, but my environment and error symptoms are very much like described above. I have an even simpler testcase, one gif that renders correctly in FF 3.0b3, another one that renders invisible! 

Should be a very easy testcase if a developer wants to have a look.

Coming up as attachments...
Robert - in what context are those invisible? Is any scaling of the image involved? That seems to be the only time that backgrounds become invisible for me. Both of those gifs render fine when viewed in Firefox.
No scaling or context whatsoever. Just put the two GIFs someplace in the filesystem and point firefox at the directory. Click on one GIF and it renders fine, click on the other and it renders invisible.

I've tested this using both 3.0b3 and the 3.0b4 rc1 from a few hours ago, same problem.

FWIW I'm running Fedora 7 and the bundled X stuff:
xorg-x11-server-Xorg-1.3.0.0-16.fc7
xorg-x11-drv-nv-2.1.3-1.fc7
(In reply to comment #23)
> I can confirm this with Xorg 7.3 and the OSS radeon driver.
> 

same for me with ATI Radeon 8500 and default (free) driver under Ubuntu Hardy alpha 6 and Firefox 3b4
Ok, I agree, it's the same bug and it depends on the X server.

Running the xorg-x11-drv-nv-2.1.6-1.fc8 server, I see the problem with some PNGs (not transparent but indexed color) not rendered at all and some GIF images rendered incorrectly, when viewed in FF3b4.

If I run X with the vesa driver, the images are rendered correctly.

Good tip; I never though to try the vesa driver.

Does anyone have a suggestion how some apps (SeaMonkey 1.1.8, Firefox 2.0.0.12--both Fedora builds) don't have the problem, but FF3 does? They're all using the same libpng. Hmm, maybe a Cairo thing?
I suspect that it is Cairo, because when I printed notok.gif to PDF, I got it
blank. More precisely it is blank in XPDF, but Ghoscript shows a black square
in the place where should be the picture, apparently because it does not
support transparency.  I don't think that the X server is involved in printing
in anyway, and as far as I know, printing in Firefox 3 is based on Cairo. Also,
the problem exists in any Firefox 3 snapshots that I found. The earliest that I
tried was April 7, 2006. All of them are based on Cairo...
The image is printed through Cairo, but the actual image is stored in an xlib surface, and that's the surface that's printed -- which is where the problem lies.  It's also wy MOZ_DISABLE_IMAGE_OPTIMIZE fixes things -- because that skips the step of uploading the image to the X server.
from the launchpad bug:
>I had to add another line in "Device" section of xorg.conf to make it work :
>
>Option "AccelMethod" "EXA"
>Option "MigrationHeuristic" "greedy"
Ah ha.. this seems to be https://bugs.freedesktop.org/show_bug.cgi?id=15098

Looks like either using EXA or setting XAANoOffscreenPixmaps can avoid the problem.
Adding "EXA" and "MigrationHeuristic" "greedy" options together had no effect.

Adding "XAANoOffscreenPixmaps" alone fixes this for my system.

Nice!
Adding relnote keyword for 1.9 -- if this doesn't get fixed in the X server, we may need to just communicate out the XAANoOffscreenPixmaps fix.
Keywords: relnote
I reported the dup above.  I can confirm this bug with the nv driver on an nVidia card, but also with *both* radeon and vesa drivers on an R250 card.  (I didn't test vesa on the nVida card.)

This only seems to get triggered when the image has an alpha channel (as reported in the dup.)

XAANoOffscreenPixmaps fixed it for me on the nVidia card (didn't test on the ATI card yet, but I assume it will fix it there too).
I can confirm that:
1) this problem shows up with the free ATI (radeon) driver under Linux.
2) This problem goes away when off-screen pixmaps are disabled via XaaNoOffScreenPixmaps
maybe there is a hacky way to workaround this in cairo somehow?
Hold on... shouldn't we be reporting something to another project about this? If disabling XaaNoOffScreenPixmaps fixes this issue, doesn't this indicate that there is a problem with fglrx? 
Sorry... ignore previous comment. This issue is occuring also with fglrx. Wasn't thinking - obviously this issue was repro'd with the radeon driver. However, that said I am using the fglrx driver and I have the same issue. 
Chris, if you read the comments you'll see it occurs with Intel and Nvidia graphic carda too.
This is now working for me, using ff3b5 as shipped with Fedora 9 beta:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008040217 Fedora/3.0-0.52.beta5.fc9 Firefox/3.0b5

Graphics: nVidia Corporation C51PV [GeForce 6150] rev 162

I can see the image attached above https://bugzilla.mozilla.org/attachment.cgi?id=307229 , as well as the images that have given me trouble until now.

I'm afraid that I'm using ffb5 also on Ubuntu, but it's not working for me.
(In reply to comment #50)
> Hold on... shouldn't we be reporting something to another project about this?
> If disabling XaaNoOffScreenPixmaps fixes this issue, doesn't this indicate that
> there is a problem with fglrx? 
> 

Agreed, I was going to do this but wanted to make sure there was no duplication of effort since this is such a common bug.  This should probably go to one or both of two places, depending if we can figure out where the problem lies: (1) the xorg bug tracker; (2) the cairo bug tracker.

(In reply to comment #54)
> This is now working for me, using ff3b5 as shipped with Fedora 9 beta:
> Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008040217
> Fedora/3.0-0.52.beta5.fc9 Firefox/3.0b5
> 
> Graphics: nVidia Corporation C51PV [GeForce 6150] rev 162
> 
> I can see the image attached above
> https://bugzilla.mozilla.org/attachment.cgi?id=307229 , as well as the images
> that have given me trouble until now.
> 

Some builds of F9 have fixed some but not all images for me.  It's a weird bug like that, there's definitely a race condition aspect to this bug.  Sometimes images will draw partially but when I scroll or refresh, they disappear again.  Sometimes a whole image blinks on for a second and then totally disappears.  This is usually only true if the image is loading progressively though (which is where the non-determinacy probably comes from, and may explain why different builds and/or hardware combos exhibit varying symptoms).
(In reply to comment #57)
> ...
> Some builds of F9 have fixed some but not all images for me.  It's a weird bug
> like that, ...

I hadn't noticed the variable behavior; the sites and images that had given me problems are solid now on scrolling or scaling. I'll keep an eye out for problems like you describe.

Also, I forgot to say, I'm using the x.org "nv" driver with no options set.
On my machine, the scaled image is black.  If I drag it I see it.  It's 100% reproducible.

Also, another corruption appears on my computer, which seems to be related to X: on some pages (with very high number of lines, or with buttons), parts of the page are shown with parts of other windows of my desktop.  See next attachment.
From xserver-xorg-core update on Ubuntu Hardy Heron:

Version 2:1.4.1~git20080131-1ubuntu8: 

  * debian/patches/165_fedora_xserver-1.5.0-xaa-option-inversion.patch:
    - Turn XAA Offscreen Pixmaps off by default, and use
      XaaOffscreenPixmaps "true" to turn them on.  This setting was an
      early pre-EXA HW optimization attempt that didn't pan out; upstream is
      deprecating XAA in favor of EXA generally, and for situations where
      XAA is still in use recommends NOT using this optimization hack, since
      they found it often just made performance worse, and sometimes created
      visualization bugs.  People wishing to gain added performance should be
      experimenting with EXA anyway, not this setting.  (closes LP: #182038)
Confirmed: this is no longer an issue in Hardy Heron. 

Can someone please update the bug subject line? It currently reads:

Scaled images rendered incorrectly; some images not shown at all (apparently Linux- & Nvidia-related)

I think a more appropriate subject line would be:

Scaled images rendered incorrectly when XAA Offscreen Pixmaps is enabled in X Server

Also, given that XAA is being deprecated and major distros like Ubuntu are disabling XaaOffscreenPixmaps by default, shouldn't the bug status be changed to WONTFIX?
I was tracking this issue in 334951.  It was suggested there that 
this was a 'cairo' problem and upgrading the xorg server to 1.4.0.90 would fix
the problem.  I upgraded last week and it seemed to work until I came across
this page:  http://heresycorner.blogspot.com/2008/04/spot-difference.html

I got the 'scaled image problem' as described in this bug report. 
I set the option "XaaNoOffscreenPixmaps" in xorg, and while this changed the
performance of X, does not resolve the problem. 

The first display of the above page showed the left image and not the right.
Reloading the page showed the previous behaviour of partial image in the upper
left hand corner and the rest of the image black.
I have xorg-sever 1.4.0.90 and xf86-video-intel 2.2.1 . 
EXA is not very usefull for me, because X crashes after a while (triggered by a popup in a IM app.). Probably some memory leak. So I must use XAA.

I also do use the
 Option      "XAANoOffscreenPixmaps" "on"
setting in xorg.conf and images are scalled ok.

*Without* the "XAANoOffscreenPixmaps" "on" option I have the bug.

ps 
I don't think WONTFIX is acceptable, not all of Fx users will upgrade their distro right-away.

pps my distro is ArchLinux
Hmm?!
I'm not sure about the format of the option, but all I have in my xorg.conf
is the following line:

        Option          "XaaNoOffscreenPixmaps"
 
without the "on"... Setting this worked for me, but I'm using the "radeonhd"
driver.
@Damjan Georgievski: I guess I'm not sure what the Firefox devs should be doing about this? If the bug is in Xaa off screen pixmaps, shouldn't there be a bug filed against xorg, not Firefox? I'm sure that this is affecting more than one area than just Firefox!
I agree.  I looked at the freedesktop.org bugs and couldn't find a dup, so I filed this bug: https://bugs.freedesktop.org/show_bug.cgi?id=15613
As stated in comment #62, Offscreen Pixmaps with XAA are, at best, a performance loss, and at worst cause rendering problems like here.  There isn't anything that Firefox can do about this; instead, we'll relnote it and move on.

While I agree that not all users will upgrade their distro right away, they can all set XAANoOffscreenPixmaps in their x configs.

So, ->INVALID, on account of not being a gecko bug.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
well it's a regression compared to previous Firefox versions.. I bet most people will downgrade the Firefox instead of changing their xorg.conf
OK. What do you expect the Firefox devs to do about it?

Of course, most distros will most likely modify xorg.conf - pretty much like Ubuntu have done. 
This is not an Xorg issue nor a xorg x config.
As I documented above, the setting of the offscreen Pixmaps parameter makes no difference.  The issue occurs whether the parameter is set or not.
Changing title as per Chris Sherlock
Summary: Scaled images rendered incorrectly; some images not shown at all (apparently Linux- & Nvidia-related) → Images rendered incorrectly when XAA Offscreen Pixmaps is enabled in X
Rich: I think the setting is "XAANoOffscreenPixmaps", so "XaaNoOffscreenPixmaps" may not work.
If that still doesn't make the bug go away for you, could you try using a different video driver like vesa or even vga to see if that solves it?
If yes then it's not a bug in mozillah or cairo.
Summary: Images rendered incorrectly when XAA Offscreen Pixmaps is enabled in X → Images (scaled, transparent) rendered incorrectly when XAA Offscreen Pixmaps is enabled in X
(In reply to comment #73)
> OK. What do you expect the Firefox devs to do about it?
> 
> Of course, most distros will most likely modify xorg.conf - pretty much like
> Ubuntu have done. 

Well, the question is how 2.0.0.x worked fine on the same configuration.
I spent some time testing this (again).
It definitely smells like a timing problem.

I got it to work correctly once with safe-mode.  
I then whittled my way through disabling all the extensions.
I then reproduced the error with safe-mode on.  
Let me say this, just because it works once in a certain configuration, does 
not mean the problem is fixed.  Because it can just as easily fail again.

I would like to request that the Headline of this bug please be changed.
This has nothing to do with XaaNoOffscreenPixmaps, as all that parameter does
is tweak the timing, and it does not fix the problem.

I'd also like to request that this bug be opened.  
This is a real problem, and until it gets diagnosed down to root cause, blaming
the X-server is not going to fix it.   
I can add some insight into the timing issue -- occasionally you can see the top part of an image (maybe the top quarter or so) appear for a split second, and then the whole image disappears.  Perhaps there is a bug in the progressive image loading code when there is an alpha channel?
I have originally reported this but after adding the XaaNoOffscreenPixmaps or whatever option to xorg.conf I could no longer reproduce. Actually my Linux machine broke since so now I am unable to test.

But maybe there are multiple unrelated bugs. There is definitely the progressively loading image disappearing after being loaded.
But if you look closely you can see parts of other non-firefox windows appear in the image as it loads, of course the pixels are offset but try opening a window with a distinctive uniform color and you will see that color appear. That really hints at an X bug.
There doesn't need to be an alpha channel at least I also got the same effect with old frames in animated GIFs being replaced by noise/other windows' contents/blank whiteness.

One thing that could by done is trying to reproduce with various builds between firefox 2 and now and see where it appears first and look at what changes happened then. Once I got Linux again I will try.

What I think happens is that X gives a buffer to firefox, it's memory has of course been previously used so it may contain other windows. Then firefox adds some parts of the loading image. In firefox 2 this buffer contained the previously decoded parts of the image but now it's a new buffer. How this happens I don't know yet. But every part of the image is decoded correctly just not put together right.
Firefox/Gecko uses server side images for speed while most other apps don't so they don't expose this issue. 

For the record I didn't have any extensions or plugins and also didn't use compiz.

I could reopen or change the title but I don't know what to..
There's a good testcase in bug #334951 comment #8
No, please do not reopen this bug.  The issue, as best I can tell, is firmly in XAA; most X developers have no interest in maintaining XAA these days, as EXA is the future.  I don't really have any interest in debugging X, so that leaves us at an impasse here.  Gecko's interaction with X is entirely through cairo; similar problems as seen here have been reported (e.g. the cairo extend-reflect testcase crashing), but I don't think anyone has been able to track down the root cause.  Disabling offscreen pixmaps fixes most of these problems; if that fix does not work, then a new bug should be filed, probably against X.

Comparing Firefox 2 to Firefox 3 isn't useful, beyond being able to see what a "working result" is -- the usage of X between the two versions is completely different.
Is someone here able to isolate a good testcase image and produce a small cairo-based program that just displays the image, and that still illustrates the problem?  Then the bug could be filed in cairo's bugzilla instead :-)  It would also definitely clear Firefox's role in the issue.
Headline title should be 
     Images (scaled, transparent) rendered incorrectly
as this problem can be reproduced independently of the 
XaaNoOffscreenPixmaps setting.
Why? It isn't evident to me that previous posters have actually configured their X Server correctly. 

I think Luke's suggestion is a good one. 
I can reproduce this problem independent of the XaaNoOffscreenPixmaps setting.
Please change the headline.  Thanks.
apparently XaaNoOffscreenPixmaps does fix some cases of this type of thing, and is resolved on that assumption, so investigating cases where it doesn't is probably more effectively done on another bug report for that purpose.
Just to say that using EXA with nv x.org driver solves all the problems for me:
- scaled images are shown
- some pages which showed garbage text with XAA now show ok
I have talked to Rich Coe via email and he had the XaaNoOffscreenPixmaps option in the wrong section. 

I believe he thinks there is still a timing problem, but I'll let him elaborate as I can't see how that would be the case. 
An update on my lack of progress.

One possible source of error is XPutImage.
An XPutImage is an XPutImage Request followed by the pixel data.  If some X call is being made on an signal handler or a different thread, this could disrupt 
this call.  XPutImage alloc's an xrequest, then analyzes the data, which may
do more work because the image doesn't fit in the box specified, and then sends
the data.  I think there's a window between the xrequest alloc and the data 
sent in which such a scenario might happen.

I started tracking down what calls XPutImage, and found that the adobe flash
plugin was being called one or more times a second, and winds up calling
XPutImage.  (why?)

A more efficient method of transferring image data to the server is through
an X shared memory protocol.  I'll have to see if this is being used.
I notice that the release notes for RC1 say this is supposedly related to NVidia
drivers, but in my case, I'm using the ATI driver.
During testing I notice that:
    the original image is 301x404
    the image as saved from the FF window is 238x320
    the destination window is approx. 202 x 271
    
Perhaps there's a bug on the code path where the original image is being reduced?
I could look and debug this if I knew where the code path was.
I've caught mozilla painting the black image

Breakpoint 4, gfxPlatform::OptimizeImage (this=0x8106644, aSurface=0x8d90eb0, 
    format=gfxASurface::ImageFormatRGB24) at /usr/local/src/moz/cvs/mozilla/gfx/thebes/src/gfxPlatform.cpp:248
248         tmpCtx.Paint();
$298 = {<gfxASurface> = {_vptr.gfxASurface = 0xb7f51488, mSurface = 0x8754000, mFloatingRefs = 0, 
    mSurfaceValid = 1 '\001'}, mSize = {width = 320, height = 320}, mOwnsData = 1, 
  mData = 0xd47b000 'ÿ' <repeats 200 times>..., mFormat = ImageFormatRGB24, mStride = 1280}
0xd47b000:      0xffffffff      0xffffffff      0xffffffff      0xffffffff
0xd47b010:      0xffffffff      0xffffffff      0xffffffff      0xffffffff
Something scribbling where they are not supposed to.

Breakpoint 8, nsJPEGDecoder::OutputScanlines (this=0x9027800)
    at /usr/local/src/moz/cvs/mozilla/modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cpp:694
694       while ((mInfo.output_scanline < mInfo.output_height)) {
0x94e5000:      0x73617274      0x632f3c74      0x543a7372      0x43656e6f
0x94e5010:      0x65767275      0x656d614e      0x20200a3e      0x20202020
(gdb) c
Continuing.
[Thread 0xb28dab90 (LWP 9263) exited]

Breakpoint 8, nsJPEGDecoder::OutputScanlines (this=0x9027800)
    at /usr/local/src/moz/cvs/mozilla/modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cpp:694
694       while ((mInfo.output_scanline < mInfo.output_height)) {
0x94e5000:      0xffffffff      0xffffffff      0xffffffff      0xffffffff
0x94e5010:      0xffffffff      0xffffffff      0xffffffff      0xffffffff
Firefox 3.0rc1 definitelly doesn't work ok by default on a Slackware 12.0 with an nvidia card.
xorg-server-1.3.0.0
xf86-video-nv-2.1.2

for ex. on this page:
http://jarlesdraw-log.blogspot.com/2008/05/svg-for-plasmoidswidgets-part-1.html
only one of the thumbnails is shown ("Projector screen closed"). Even if I go to the "page information" dialog the images are not shown.

At the same time enabling EXA crashes the X server, and also the "XAA..." option crashes the X server too.

Konqueror works fine, and so does Firefox 2.0.0.14.

This 
This bug is still closed; any chance that it can be re-opened given the large number of users it affects?  (The bug even made the RC1 release notes :) )

If nothing else, there has to be a workaround even if it is not a FF problem, as other programs work fine.

I would think this bug should be a showstopper for 3.0 as it makes the display of some websites quite broken.
(In reply to comment #94)
> I've caught mozilla painting the black image
> 
> Breakpoint 4, gfxPlatform::OptimizeImage (this=0x8106644, aSurface=0x8d90eb0, 
>     format=gfxASurface::ImageFormatRGB24) at
> /usr/local/src/moz/cvs/mozilla/gfx/thebes/src/gfxPlatform.cpp:248
> 248         tmpCtx.Paint();
> $298 = {<gfxASurface> = {_vptr.gfxASurface = 0xb7f51488, mSurface = 0x8754000,
> mFloatingRefs = 0, 
>     mSurfaceValid = 1 '\001'}, mSize = {width = 320, height = 320}, mOwnsData =
> 1, 
>   mData = 0xd47b000 'ÿ' <repeats 200 times>..., mFormat = ImageFormatRGB24,
> mStride = 1280}
> 0xd47b000:      0xffffffff      0xffffffff      0xffffffff      0xffffffff
> 0xd47b010:      0xffffffff      0xffffffff      0xffffffff      0xffffffff
> 

i would think 0xfffff.. is white
I reduced my testing down to a single page with two images. 
I've verified the pixels look reasonable in the mData pointer after jpeg
decompress.
I haven't been able to find the code that copies the data from the mData 
pointer into a cairo surface.  
What's really weird is that every time the page gets re-painted, FF goes
through this weird dance where:
  -- go through the jpeg decompressor (nothing to do)
  -- alloc a cairo pattern to point to an existing cairo surface
  -- copy cairo pattern to brand new cairo offscreen image 
  -- copy cairo offscreen image to existing xlib surface
At worst, this is very inefficient.  
At best, it's very confusing.

Here's another work-around.  Grab the image with the mouse and drag.
The correct image will appear in a drag window.
that's not really a work around. I also concur that this should be a show stopper. I think that it must only partially be an Xorg bug as it didn't exist in ff2
If anybody is wondering why this bug magically fixed itself in their distro recently, it's because Ubuntu and Fedora have inverted the default behavior of the XAANoOffscreenPixmaps option.

https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/182038/comments/111

In case you're trying to debug this, you may need one of the following options to bring back the broken behavior:

	Option	    "XAANoOffscreenPixmaps" "false"
	Option	    "XAAOffscreenPixmaps" "true"

Seems like sweeping things under the rug to me :o)
Does anyone else see this rendering bug too? It only appears when I switch back off-screen pixmaps.

Or is it unrelated? Similar glitches are also present in other programs like GNOME 2.22 Appearance dialog or the scrollbars in every app in KDE 4...

It would be best if Xorg was willing to fix it including backports to old X releases
I think there are actually two problems here.  This is an image that manifests the "black box" problem.  Create the following HTML file in the same directory, and watch the image as it resizes.  There seems to be a problem with calculating image offsets inside the clipping region, because for medium image sizes, the image displays but is vertically offset, and surrounded by black above or below; as the image's size continues to get bigger, the image that should be displayed moves upwards at about twice the speed of the increase in display size.  For large or small sizes, the image shows as completely black, because the image content is being displayed above or below the clip region.

<html>
<head>
<script type="text/javascript">
function f() {
  var img = document.getElementById('pic');
  img.width += 100;
  if (img.width > 1700)
    img.width = 100;
  setTimeout('f()', 1000);
}
</script>
</head>
<body onload="javascript:f()">
<img src="kde4.0.png" id="pic"/>
</body>

The second problem is to do with transparency (not resizing), and displays a white image rather than a black image.  I will attach an example below.
This image is a PNG with an alpha channel, and does not display at all in FF3.  Just go "firefox tmp.png" to see it (or not as the case may be :) ).

Running the script in the comment above on this image does *not* cause the image to be shown at certain sizes.  Therefore it seems that this is an unrelated problem to do with alpha channels in images.
PS you can also see the black box problem by opening the image in attachment 321843 [details] directly in FF3, and then holding Ctrl while rolling the mousewheel to zoom in and out.
The xorg bug is actually at this address:

https://bugs.freedesktop.org/show_bug.cgi?id=15098
In case you can't duplicate this problem by running the JS code I posted above, here is an animated GIF of the image resizing problem.

http://web.mit.edu/~luke_h/www/anim.gif

Actually I think this bug may cover three different issues, not two: wrong image offset calculations, easily spotted in this animation; the transparency problem, previously discussed; and also there seems to be a third problem with uninitialized memory with certain sizes of these "black box" cases.  You can see some dim brown stripes that run down the black box in the first frame of this animation.  If you stop the JS code running at that point and open another window, the pattern of lines changes, it's like the first row of the black box is pulling in data from some X shared memory, and that is copied all the way down.  Dragging another window over the top of the black box causes trails to be left behind.

Ironically, on a "broken system", the above animated gif displays wrong too, it gets cropped into a narrow wide box near the top of the browser window, and as it animates, some window decoration junk gets inserted at the edges of the box along with content of the gif animation itself...
An example of the uninitialized memory problem: with the image scaled to the smallest size, it starts out with random gray stripes running from top to bottom, and then if you stop the JS code running and drag a window past the black box, you get something like this.
Sorry for all the comment spam... one more distinction between these problems: with the "black box problem", dragging the black box shows the correct image in the tooltip.  With the "invisible image with transparency" problem, dragging the area of the browser window that should be showing the image does *not* show anything.  However zooming in far enough with Ctrl-Scrollwheel eventually adds scrollbars to the browser window, so the image is there in the DOM, it's just not being displayed, and it seems that it's definitely a different problem in both cases.
I changed from using fglrx to radeonhd to fix another issue, and I can't 
reproduce the problem on my platform.
I have found that using ``Option "XaaNoOffscreenPixmaps"'' slows down
some xscreensaver programs (fuzzyflakes, deluxe, twang). What I have done,
instead, is to run the X server using ``DefaultDepth 16'' instead of 24.
This fixes the problem fine for me.

System specs (in case it helps):
X :  xorg-6.9.0
GPU: nVidia GeForce2 MX Integrated Graphics (pci id: 10de:01a0 (rev b1))
MEM: 32MB shared (main memory 256 MB). 32MB graphics aperture size.
MB:  Asus A7N266-VM
CPU: AMD Athlon(TM) XP 2000+
Hardware: PC → All
Summary: Images (scaled, transparent) rendered incorrectly when XAA Offscreen Pixmaps is enabled in X → Images rendered incorrectly when XAA Offscreen Pixmaps are enabled in X and the color depth is 24 bits
I see this is marked RESOLVED INVALID and I understand the reason why, but I do want to point out that I see this bug on Firefox's DEFAULT Google start page http://www.google.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official on Mandriva 2008.1 on X.Org X Server 1.4.0.90 with nv driver. The Firefox-Google logo http://www.google.com/images/firefox/sprite.png does not show.  Will Google want to weigh in on this, maybe with a workaround, so that we don't receive an avalanche of reports with FFX3?
1st of all sorry if this is not the right place to discuss it, but I wouldn't know the "right" place.

I can understand this is not a bug but what I see is a whole bunch of users not being able to use FF3 because of this "issue". I'll be sticking to 2.x, since most of the sites (and my own among them) are not going to work with FF3.

If more and more users (almost everyone using 24bit? perhaps) will be having this kind of "issue", well, it won't be a good.

(Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0)


WHERE TO PUT THE XAANoOffscreenPixmaps configuration option.

This is for anyone who (like me) was wondering precisely where to put the above option. These are the details for my system (OpenSuse 10.3).

Location /etc/X11/xorg.conf

...
Section "Device"
  BoardName    "GeForce4 Go DH"
  BusID        "1:0:0"
  Driver       "nv"
  Identifier   "Device[0]"
  Screen       0
  VendorName   "NVidia"
  Option       "XAANoOffscreenPixmaps" "on"
EndSection
...

This solved my problem with one of the background images not loading properly in Facebook.
(In reply to comment #116)
> WHERE TO PUT THE XAANoOffscreenPixmaps configuration option.
> 
> This is for anyone who (like me) was wondering precisely where to put the above
> option. These are the details for my system (OpenSuse 10.3).
> 
> Location /etc/X11/xorg.conf
> 
> ...
> Section "Device"
>   BoardName    "GeForce4 Go DH"
>   BusID        "1:0:0"
>   Driver       "nv"
>   Identifier   "Device[0]"
>   Screen       0
>   VendorName   "NVidia"
>   Option       "XAANoOffscreenPixmaps" "on"
> EndSection
> ...
> 
> This solved my problem with one of the background images not loading properly
> in Facebook.
> 

I have just tried to use the "XAANoOffscreenPixmaps" option on my Opensuse 10.3 system. I use a Nvidia GeForce 7800 GTX card with the latest Nvidia driver 173.14.05 on a X86_64 architecture. I tried the option with and without the trailing "on". The xorg X-server version is 7.2.0 (7.2.0-135.4 rpm package from SuSE). All relevant rpm packages for the system are from the SuSE repositories. KDE version is 3.5.9.      

The settings did not change anything regarding the bad FF 3.0 image scaling on this system. The scaling quality remains that of a nearest neighbor interpolation as with FF 2.x. So it seems that there are more factors involved than just the XAA thing. At least when you use the drivers from Nvidia.  
 
This bug has nothing to do with image scaling quality. The bug for that is bug 422179.
Just so everyone is aware - Freedesk xorg hackers already know what the issue is. 

See http://bugs.freedesktop.org/show_bug.cgi?id=13795

"The issue here is almost certainly that FbComposite offsets the composite
operation by the coordinates of the drawable with no regard to the
transformation. 

Fixing probably involves making image_from_pict() do the conversion, and
somehow fixing up miSourceValidate"

The final action in the bug that we logged is below, that bug can be found at http://bugs.freedesktop.org/show_bug.cgi?id=15098 

"I really can't be **** to fix this properly right now, XAA is just dire.  For
7.4 I'm just going to turn off XAA offscreen pixmaps by default, they end up
being a performance loss in most cases anyway."
(In reply to comment #114)
> I see this is marked RESOLVED INVALID and I understand the reason why, but I do
> want to point out that I see this bug on Firefox's DEFAULT Google start page
> http://www.google.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official
> on Mandriva 2008.1 on X.Org X Server 1.4.0.90 with nv driver. The

Mandriva should fix their default x org settings. I know that ubuntu and fedora do that.

seems like xorg 1.6.0 dropped the patch that disabled offscreen pixmaps for xaa by default (still needs investigation why).

So this bug reappeared in jaunty.

See: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/316136

FWIW, we will patch xorg in ubuntu accordingly again; so still no action from mozilla side needed.
Another note: I encountered this problem with the "intel" driver, using the G45 chipset graphics.

It was necessary for me to use the following two entries in the Device section of xorg.conf. "RenderAccel" explicitly turns on EXA. The XAANoOffscreenPixmaps alone would not fix the problem:

	Option		"XAANoOffscreenPixmaps" "on"
	Option		"RenderAccel" "on"
You need to log in before you can comment on or make changes to this bug.