Last Comment Bug 411831 - Images rendered incorrectly when XAA Offscreen Pixmaps are enabled in X and the color depth is 24 bits
: Images rendered incorrectly when XAA Offscreen Pixmaps are enabled in X and t...
Status: RESOLVED INVALID
: relnote
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All Linux
: -- major with 12 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://web.mit.edu/~luke_h/www/anim.gif
: 409345 414928 416243 418826 419224 419611 422996 423068 423191 423479 425242 425448 425633 426282 427447 428261 429641 430044 437428 439109 440518 441181 441369 442451 450097 457575 470724 472472 472564 473130 477292 485694 497220 502455 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-10 17:54 PST by Γριφεγ
Modified: 2011-01-30 13:07 PST (History)
60 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
The site mugshot.org in Firefox (118.52 KB, image/png)
2008-01-10 17:56 PST, Γριφεγ
no flags Details
The same site (mugshot.org) in WebKit for comparison (299.86 KB, image/png)
2008-01-10 17:58 PST, Γριφεγ
no flags Details
An unscaled image, correctly rendered (148.20 KB, image/png)
2008-01-30 03:50 PST, Greg K Nicholson [:gkn]
no flags Details
The same image, scaled, renders incorrectly (152.59 KB, image/png)
2008-01-30 03:54 PST, Greg K Nicholson [:gkn]
no flags Details
The BBC homepage beta in Firefox 2 (134.96 KB, image/png)
2008-01-30 04:23 PST, Greg K Nicholson [:gkn]
no flags Details
The BBC homepage beta in Firefox 3 (130.51 KB, image/png)
2008-01-30 04:27 PST, Greg K Nicholson [:gkn]
no flags Details
Screenshots: scaling, opaque vs. transparent images (274.78 KB, application/x-gzip)
2008-01-30 05:40 PST, Greg K Nicholson [:gkn]
no flags Details
Transparent GIF, renders correctly (3.51 KB, image/gif)
2008-03-04 06:25 PST, Robert Andersson
no flags Details
Transparent GIF, renders incorrect as invisible (5.74 KB, image/gif)
2008-03-04 06:25 PST, Robert Andersson
no flags Details
Show parts of desktop windows when showing some pages (247.82 KB, image/png)
2008-04-09 10:28 PDT, Eugen Dedu
no flags Details
Image rendering bug manifesting in the Preferences dialog (42.82 KB, image/png)
2008-05-20 14:28 PDT, Γριφεγ
no flags Details
an image that manifests the "black box" problem (245.98 KB, image/png)
2008-05-20 16:05 PDT, Luke Hutchison
no flags Details
an image that manifests the "invisible image" problem (13.11 KB, image/png)
2008-05-20 16:07 PDT, Luke Hutchison
no flags Details
an image that manifests the "uninitialized memory" problem (662 bytes, image/png)
2008-05-21 10:00 PDT, Luke Hutchison
no flags Details

Description Γριφεγ 2008-01-10 17:54:09 PST
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.
Comment 1 Γριφεγ 2008-01-10 17:56:41 PST
Created attachment 296456 [details]
The site mugshot.org in Firefox
Comment 2 Γριφεγ 2008-01-10 17:58:13 PST
Created attachment 296457 [details]
The same site (mugshot.org) in WebKit for comparison
Comment 3 Γριφεγ 2008-01-10 20:52:17 PST
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)
Comment 4 Greg K Nicholson [:gkn] 2008-01-30 03:47:32 PST
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.
Comment 5 Greg K Nicholson [:gkn] 2008-01-30 03:50:10 PST
Created attachment 300345 [details]
An unscaled image, correctly rendered

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.
Comment 6 Greg K Nicholson [:gkn] 2008-01-30 03:54:24 PST
Created attachment 300346 [details]
The same image, scaled, renders incorrectly

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.
Comment 7 Greg K Nicholson [:gkn] 2008-01-30 03:57:07 PST
*** Bug 409345 has been marked as a duplicate of this bug. ***
Comment 8 Greg K Nicholson [:gkn] 2008-01-30 04:00:37 PST
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.
Comment 9 Greg K Nicholson [:gkn] 2008-01-30 04:09:06 PST
This is not PNG-specific – background GIF images disappear from the BBC homepage beta in Fx 3; screenshots to follow.
Comment 10 Greg K Nicholson [:gkn] 2008-01-30 04:23:13 PST
Created attachment 300351 [details]
The BBC homepage beta in Firefox 2

This page renders correctly in Firefox 2 (aside from the black box around the Flash clock).
Comment 11 Greg K Nicholson [:gkn] 2008-01-30 04:27:49 PST
Created attachment 300352 [details]
The BBC homepage beta in Firefox 3

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.
Comment 12 Greg K Nicholson [:gkn] 2008-01-30 05:40:19 PST
Created attachment 300358 [details]
Screenshots: scaling, opaque vs. transparent 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.
Comment 13 Greg K Nicholson [:gkn] 2008-01-30 06:03:50 PST
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.
Comment 14 Γριφεγ 2008-01-31 06:57:28 PST
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.
Comment 15 kripkenstein 2008-01-31 07:08:37 PST
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.
Comment 16 Greg K Nicholson [:gkn] 2008-01-31 07:19:57 PST
(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 .
Comment 17 kripkenstein 2008-01-31 07:22:30 PST
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

Comment 18 Γριφεγ 2008-01-31 11:34:49 PST
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.
Comment 19 Damjan Georgievski 2008-02-19 01:20:55 PST
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.
Comment 20 Alexander Sack 2008-02-26 05:15:26 PST
dupe of bug 380115 ?
Comment 21 Alexander Sack 2008-02-26 05:17:16 PST
if you see this, please test if the latest patch in there fixes your issue as well.
Comment 22 Greg K Nicholson [:gkn] 2008-02-26 12:35:57 PST
*** Bug 419611 has been marked as a duplicate of this bug. ***
Comment 23 saurabh 2008-02-26 21:48:20 PST
I can confirm this with Xorg 7.3 and the OSS radeon driver.
Comment 24 Robert Andersson 2008-03-04 06:24:03 PST
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...
Comment 25 Robert Andersson 2008-03-04 06:25:07 PST
Created attachment 307228 [details]
Transparent GIF, renders correctly
Comment 26 Robert Andersson 2008-03-04 06:25:45 PST
Created attachment 307229 [details]
Transparent GIF, renders incorrect as invisible
Comment 27 saurabh 2008-03-04 08:54:10 PST
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.
Comment 28 Robert Andersson 2008-03-04 13:47:13 PST
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
Comment 29 antistress 2008-03-15 19:14:50 PDT
(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
Comment 30 Bryan Bach 2008-03-16 13:40:30 PDT
*** Bug 419224 has been marked as a duplicate of this bug. ***
Comment 31 Matthias Versen [:Matti] 2008-03-16 19:16:17 PDT
*** Bug 422996 has been marked as a duplicate of this bug. ***
Comment 32 Dmitry Potapov 2008-03-16 21:00:17 PDT
*** Bug 423191 has been marked as a duplicate of this bug. ***
Comment 33 Joe Smith 2008-03-16 21:14:57 PDT
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?
Comment 34 Dmitry Potapov 2008-03-16 22:22:44 PDT
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...
Comment 35 Vladimir Vukicevic [:vlad] [:vladv] 2008-03-16 23:41:03 PDT
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.
Comment 36 Matthias Versen [:Matti] 2008-03-17 02:13:51 PDT
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"
Comment 37 Vladimir Vukicevic [:vlad] [:vladv] 2008-03-17 14:54:31 PDT
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.
Comment 38 Matthias Versen [:Matti] 2008-03-17 18:46:37 PDT
*** Bug 423479 has been marked as a duplicate of this bug. ***
Comment 39 Joe Smith 2008-03-17 18:48:44 PDT
Adding "EXA" and "MigrationHeuristic" "greedy" options together had no effect.

Adding "XAANoOffscreenPixmaps" alone fixes this for my system.

Nice!
Comment 40 Vladimir Vukicevic [:vlad] [:vladv] 2008-03-17 19:40:35 PDT
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.
Comment 41 Luke Hutchison 2008-03-25 13:35:53 PDT
*** Bug 416243 has been marked as a duplicate of this bug. ***
Comment 42 Luke Hutchison 2008-03-25 13:41:19 PDT
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).
Comment 43 Matthias Versen [:Matti] 2008-03-26 13:18:45 PDT
*** Bug 425242 has been marked as a duplicate of this bug. ***
Comment 44 Matthias Versen [:Matti] 2008-03-26 13:20:09 PDT
*** Bug 414928 has been marked as a duplicate of this bug. ***
Comment 45 david.hagood 2008-03-26 18:13:33 PDT
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
Comment 46 Laurent Bonnaud 2008-03-28 01:46:25 PDT
*** Bug 425448 has been marked as a duplicate of this bug. ***
Comment 47 Matthias Versen [:Matti] 2008-03-28 11:50:52 PDT
*** Bug 425633 has been marked as a duplicate of this bug. ***
Comment 48 Antonio M. D'souza 2008-04-01 07:44:30 PDT
*** Bug 426282 has been marked as a duplicate of this bug. ***
Comment 49 Alexander Sack 2008-04-05 20:42:49 PDT
maybe there is a hacky way to workaround this in cairo somehow?
Comment 50 Chris Sherlock 2008-04-06 04:34:35 PDT
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? 
Comment 51 Chris Sherlock 2008-04-06 04:41:03 PDT
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. 
Comment 52 Damjan Georgievski 2008-04-06 06:13:40 PDT
Chris, if you read the comments you'll see it occurs with Intel and Nvidia graphic carda too.
Comment 53 Matthias Versen [:Matti] 2008-04-06 14:11:03 PDT
*** Bug 423068 has been marked as a duplicate of this bug. ***
Comment 54 Joe Smith 2008-04-06 16:38:14 PDT
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.

Comment 55 Matthias Versen [:Matti] 2008-04-06 18:50:54 PDT
*** Bug 427447 has been marked as a duplicate of this bug. ***
Comment 56 Chris Sherlock 2008-04-07 05:14:03 PDT
I'm afraid that I'm using ffb5 also on Ubuntu, but it's not working for me.
Comment 57 Luke Hutchison 2008-04-07 05:38:34 PDT
(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).
Comment 58 Joe Smith 2008-04-07 06:07:05 PDT
(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.
Comment 59 Eugen Dedu 2008-04-09 10:21:21 PDT
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.
Comment 60 Eugen Dedu 2008-04-09 10:28:08 PDT
Created attachment 314634 [details]
Show parts of desktop windows when showing some pages

Go to http://atilf.atilf.fr/dendien/scripts/tlfiv4/showps.exe?p=combi.htm;java=no; type erreur and Valider.  I obtain this screenshot.
Comment 61 Matthias Versen [:Matti] 2008-04-10 02:23:30 PDT
*** Bug 428261 has been marked as a duplicate of this bug. ***
Comment 62 Chris Sherlock 2008-04-17 03:59:15 PDT
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)
Comment 63 Chris Sherlock 2008-04-17 04:00:30 PDT
Sorry for bug spam. 

Launchpad URL:

https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/182038
Comment 64 Chris Sherlock 2008-04-17 04:33:29 PDT
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?
Comment 65 Rich Coe 2008-04-17 09:24:19 PDT
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.
Comment 66 Matthias Versen [:Matti] 2008-04-18 09:20:13 PDT
*** Bug 429641 has been marked as a duplicate of this bug. ***
Comment 67 Damjan Georgievski 2008-04-19 13:24:38 PDT
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
Comment 68 Sven Anders 2008-04-19 13:33:56 PDT
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.
Comment 69 Chris Sherlock 2008-04-19 16:37:50 PDT
@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!
Comment 70 Luke Hutchison 2008-04-19 19:49:55 PDT
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
Comment 71 Vladimir Vukicevic [:vlad] [:vladv] 2008-04-19 21:35:05 PDT
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.
Comment 72 Damjan Georgievski 2008-04-20 06:49:17 PDT
well it's a regression compared to previous Firefox versions.. I bet most people will downgrade the Firefox instead of changing their xorg.conf
Comment 73 Chris Sherlock 2008-04-20 14:59:44 PDT
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. 
Comment 74 Rich Coe 2008-04-21 05:52:35 PDT
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.
Comment 75 Γριφεγ 2008-04-21 06:04:55 PDT
Changing title as per Chris Sherlock
Comment 76 Matthias Versen [:Matti] 2008-04-21 07:44:36 PDT
*** Bug 430044 has been marked as a duplicate of this bug. ***
Comment 77 Γριφεγ 2008-04-21 08:27:13 PDT
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.
Comment 78 Damjan Georgievski 2008-04-22 06:48:25 PDT
(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.
Comment 79 Rich Coe 2008-04-22 21:43:11 PDT
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.   
Comment 80 Luke Hutchison 2008-04-22 21:49:53 PDT
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?
Comment 81 Γριφεγ 2008-04-23 15:15:09 PDT
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..
Comment 82 Γριφεγ 2008-04-23 16:03:46 PDT
There's a good testcase in bug #334951 comment #8
Comment 83 Vladimir Vukicevic [:vlad] [:vladv] 2008-04-23 22:24:21 PDT
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.
Comment 84 Luke Hutchison 2008-04-23 22:40:04 PDT
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.
Comment 85 Rich Coe 2008-04-27 06:17:18 PDT
Headline title should be 
     Images (scaled, transparent) rendered incorrectly
as this problem can be reproduced independently of the 
XaaNoOffscreenPixmaps setting.
Comment 86 Chris Sherlock 2008-04-28 03:52:56 PDT
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. 
Comment 87 Rich Coe 2008-04-28 06:32:56 PDT
I can reproduce this problem independent of the XaaNoOffscreenPixmaps setting.
Please change the headline.  Thanks.
Comment 88 Tuukka Tolvanen (sp3000) 2008-04-28 12:08:03 PDT
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.
Comment 89 Eugen Dedu 2008-05-05 00:52:49 PDT
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
Comment 90 Chris Sherlock 2008-05-06 00:20:05 PDT
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. 
Comment 91 Rich Coe 2008-05-15 04:43:21 PDT
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.
Comment 92 Rich Coe 2008-05-18 08:30:40 PDT
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.
Comment 93 Rich Coe 2008-05-18 09:38:06 PDT
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.
Comment 94 Rich Coe 2008-05-18 13:50:30 PDT
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
Comment 95 Rich Coe 2008-05-19 12:11:39 PDT
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
Comment 96 Damjan Georgievski 2008-05-20 10:21:16 PDT
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 
Comment 97 Luke Hutchison 2008-05-20 11:31:57 PDT
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.
Comment 98 Γριφεγ 2008-05-20 12:15:28 PDT
(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
Comment 99 Rich Coe 2008-05-20 12:59:39 PDT
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.
Comment 100 Caleb Cushing 2008-05-20 13:14:33 PDT
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
Comment 101 Luke Hutchison 2008-05-20 13:19:31 PDT
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)
Comment 102 Γριφεγ 2008-05-20 14:28:13 PDT
Created attachment 321823 [details]
Image rendering bug manifesting in the Preferences dialog

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
Comment 103 Luke Hutchison 2008-05-20 16:05:11 PDT
Created attachment 321843 [details]
an image that manifests the "black box" problem

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.
Comment 104 Luke Hutchison 2008-05-20 16:07:17 PDT
Created attachment 321844 [details]
an image that manifests the "invisible image" problem

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.
Comment 105 Luke Hutchison 2008-05-20 16:08:43 PDT
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.
Comment 106 Chris Sherlock 2008-05-21 03:09:33 PDT
The xorg bug is actually at this address:

https://bugs.freedesktop.org/show_bug.cgi?id=15098
Comment 107 Luke Hutchison 2008-05-21 09:57:31 PDT
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...
Comment 108 Luke Hutchison 2008-05-21 10:00:27 PDT
Created attachment 321964 [details]
an image that manifests the "uninitialized memory" problem

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.
Comment 109 Luke Hutchison 2008-05-21 10:08:21 PDT
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.
Comment 110 Rich Coe 2008-06-05 06:30:53 PDT
I changed from using fglrx to radeonhd to fix another issue, and I can't 
reproduce the problem on my platform.
Comment 111 Rajeev V. Pillai 2008-06-07 18:04:13 PDT
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+
Comment 112 Mateo Matachana López 2008-06-09 17:04:18 PDT
*** Bug 437428 has been marked as a duplicate of this bug. ***
Comment 113 Matthias Versen [:Matti] 2008-06-13 21:59:04 PDT
*** Bug 439109 has been marked as a duplicate of this bug. ***
Comment 114 DStile 2008-06-14 18:31:01 PDT
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?
Comment 115 william maddler 2008-06-15 12:34:04 PDT
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)


Comment 116 Marcus Clyne 2008-06-18 02:24:01 PDT
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.
Comment 117 Ralph Moenchmeyer 2008-06-18 06:03:02 PDT
(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.  
 
Comment 118 Ryan VanderMeulen [:RyanVM] 2008-06-18 06:06:53 PDT
This bug has nothing to do with image scaling quality. The bug for that is bug 422179.
Comment 119 Chris Sherlock 2008-06-18 19:13:50 PDT
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."
Comment 120 Matthias Versen [:Matti] 2008-06-22 23:02:22 PDT
*** Bug 441181 has been marked as a duplicate of this bug. ***
Comment 121 Alexander Sack 2008-06-24 12:29:48 PDT
(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.

Comment 122 timeless 2008-07-13 05:37:01 PDT
*** Bug 441369 has been marked as a duplicate of this bug. ***
Comment 123 Matthias Versen [:Matti] 2008-08-11 07:38:54 PDT
*** Bug 450097 has been marked as a duplicate of this bug. ***
Comment 124 Kevin Brosnan 2008-08-16 12:38:48 PDT
*** Bug 440518 has been marked as a duplicate of this bug. ***
Comment 125 Håvar I. Henriksen 2008-09-28 23:08:40 PDT
*** Bug 457575 has been marked as a duplicate of this bug. ***
Comment 126 Matthias Versen [:Matti] 2008-11-03 14:32:12 PST
*** Bug 442451 has been marked as a duplicate of this bug. ***
Comment 127 Matthias Versen [:Matti] 2008-12-21 21:56:39 PST
*** Bug 470724 has been marked as a duplicate of this bug. ***
Comment 128 Matthias Versen [:Matti] 2009-01-07 16:46:39 PST
*** Bug 472564 has been marked as a duplicate of this bug. ***
Comment 129 Nick Welch 2009-01-07 21:37:41 PST
*** Bug 472472 has been marked as a duplicate of this bug. ***
Comment 130 Matthias Versen [:Matti] 2009-01-12 01:22:51 PST
*** Bug 473130 has been marked as a duplicate of this bug. ***
Comment 131 Alexander Sack 2009-01-13 06:55:11 PST
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.
Comment 132 Matthias Versen [:Matti] 2009-02-07 09:10:01 PST
*** Bug 477292 has been marked as a duplicate of this bug. ***
Comment 133 Kevin Brosnan 2009-07-07 07:14:53 PDT
*** Bug 497220 has been marked as a duplicate of this bug. ***
Comment 134 Richard A 2009-07-07 08:00:11 PDT
*** Bug 502455 has been marked as a duplicate of this bug. ***
Comment 135 Richard A 2009-07-07 08:03:59 PDT
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"
Comment 136 Kevin Brosnan 2010-05-12 13:29:26 PDT
*** Bug 485694 has been marked as a duplicate of this bug. ***
Comment 137 Brian Carpenter [:geeknik] 2010-08-28 18:42:37 PDT
*** Bug 418826 has been marked as a duplicate of this bug. ***

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