Black rectangle instead of image in FF3 [Hardy]

Bug #182038 reported by kripken
244
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Invalid
High
X.Org X server
Fix Released
Critical
XULRunner
Invalid
High
epiphany-browser (Ubuntu)
Undecided
Unassigned
firefox-3.0 (Ubuntu)
Medium
Alexander Sack
imagezoom (Ubuntu)
Undecided
Unassigned
xorg-server (Ubuntu)
Medium
Bryce Harrington
xulrunner-1.9 (Ubuntu)
Medium
Alexander Sack

Bug Description

workarounds:

1. use in-source jpeg (in xulrunner 1.9 >= beta5)
2. use Option "XAANoOffscreenPixmaps" "true" in your xorg.conf device section.

Binary package hint: firefox-3.0

Firefox 3.0 renders images fine at the default zoom, but for certain images shows only a black rectangle when the zoom is changed (by control-+ or control--). See e.g. this page:

http://www.everex.com/

There is a big image of a laptop on the right. This turns into a black rectangle when the zoom is not the default.

This is on a fresh install of Hardy Heron Alpha 3. I am using the "nv" open-source driver if that is relevant.

Revision history for this message
In , Γριφεγ (grfgguvf) wrote :

Created an attachment (id=296456)
The site mugshot.org in Firefox

Revision history for this message
In , Γριφεγ (grfgguvf) wrote :

Created an attachment (id=296457)
The same site (mugshot.org) in WebKit for comparison

Revision history for this message
In , Γριφεγ (grfgguvf) wrote :

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)

Revision history for this message
kripken (kripkenstein) wrote : Black rectangle instead of image in FF3/Hardy

Binary package hint: firefox-3.0

Firefox 3.0 renders images fine at the default zoom, but for certain images shows only a black rectangle when the zoom is changed (by control-+ or control--). See e.g. this page:

http://www.everex.com/

There is a big image of a laptop on the right. This turns into a black rectangle when the zoom is not the default.

This is on a fresh install of Hardy Heron Alpha 3. I am using the "nv" open-source driver if that is relevant.

Revision history for this message
kripken (kripkenstein) wrote :

Looking at some other websites, I now notice that sometimes images are just not shown - at any zoom. Example:

http://arstechnica.com/news.ars/post/20080111-kde-4-0-rough-but-ready-for-action.html

There is a screenshot (PNG, not sure if that is important) that doesn't show up at all - just a blank area, same color as the background, where the image should be,

Revision history for this message
Mb (mb-deactivatedaccount-deactivatedaccount-deactivatedaccount) wrote :

I can't reproduce this. I'm on a updated Hardy.

Revision history for this message
kripken (kripkenstein) wrote :

Mario: Well, perhaps it's something more specific. I'm using the "nv" open-source driver. Are you using binary drivers perhaps?

Revision history for this message
Mb (mb-deactivatedaccount-deactivatedaccount-deactivatedaccount) wrote :

Yes, it could be that. I confirm that I'm using the "nvidia" driver and the problem doesn't occurr. :)

Revision history for this message
Nanley Chery (nanoman) wrote :

Same problem using the nv driver. Haven't tried the nvidia driver. Also, could bug 180525 be a duplicate?

Revision history for this message
kripken (kripkenstein) wrote :

I now think that indeed this and bug #18525 may be closely related, good point, Nanley. When resizing, all sorts of odd things occur to images, the 'black rectangles' reported in this bug may just be what happens when the image is moved out of the visual area completely. In other cases I have seen it moved partially out of the visual area.

So, is the "nv" driver the issue here? Perhaps this might explain why there isn't a flood of reports of this bug.

Revision history for this message
kripken (kripkenstein) wrote :

I am attaching screenshots of an example, on a familiar website. Here it is at default zoom:

Revision history for this message
kripken (kripkenstein) wrote :

And here it is when zoomed in one time. Note the black rectangle instead of the central image:

Revision history for this message
Nanley Chery (nanoman) wrote :

This is most definitely a problem in the nv driver as installing the nvdia driver fixed this problem for me and others.

Changed in xserver-xorg-driver-nv:
status: New → Confirmed
Revision history for this message
sojourner (itsmealso2) wrote :

I also confirm that this occurs with the NV driver but not with the Nvidia propriatary driver ( 169.04 64 bit ).

Revision history for this message
Alexander Sack (asac) wrote :

please attach an image that is affected (not screenshot, but the actual image).

Thanks,
 - Alexander

Changed in firefox-3.0:
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
kripken (kripkenstein) wrote :

Here is an example image.

Appears as a black rectangle at all but the default zoom using "nv" (works fine with "nvidia").

Revision history for this message
Alexander Sack (asac) wrote :

thanks, does it happen with all jpegs or just with some? are there pngs or gifs that don't work either?

Changed in xorg-server:
status: Unknown → Confirmed
Revision history for this message
kripken (kripkenstein) wrote :

This does not happen with all jpegs. For example, open www.ubuntu.com: the middle top jpeg (the one I attached above) has the problem, but the one on the left (with the four people, http://www.ubuntu.com/files/masthead/ulivecfp/masthead-left-gutsy.jpg) - is fine. However, this is 100% consistent - certain jpegs have the problem, and always do, in all of my testing. (No idea what makes certain ones vulnerable to this.)

Regarding PNG images, there are other serious issues with them. In some cases - not all - they completely fail to load, leaving an empty area, not even a black rectangle, and this occurs for ALL zoom levels. There is a bug at Mozilla here:

https://bugzilla.mozilla.org/show_bug.cgi?id=409345

An example page for testing is this:

http://www.canonical.com/projects/landscape

There should be several screenshots, but none appear when using the "nv" driver - there is just blank space. Sometimes the images load partially, but scrolling away and then back makes them vanish. All of this works with the "nvidia" binary driver, so again, the issues are with the "nv" driver.

Revision history for this message
Alexander Sack (asac) wrote :

maybe try to use the EXA accelmethod (instead of XAA) in your xorg.conf.

Revision history for this message
kripken (kripkenstein) wrote :

EXA doesn't help - still black rectangles and the other problems.

(FWIW I noticed that EXA is faster than XAA.)

Revision history for this message
In , Grey Nicholson (greytheearthling) wrote :

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.

Revision history for this message
In , Grey Nicholson (greytheearthling) wrote :

Created an attachment (id=300345)
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.

Revision history for this message
In , Grey Nicholson (greytheearthling) wrote :

Created an attachment (id=300346)
The same image, scaled, renders incorrectly

This is the same image as attachment 300345, 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.

Revision history for this message
In , Grey Nicholson (greytheearthling) wrote :

*** Bug 409345 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Grey Nicholson (greytheearthling) wrote :

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.

Revision history for this message
In , Grey Nicholson (greytheearthling) wrote :

This is not PNG-specific – background GIF images disappear from the BBC homepage beta in Fx 3; screenshots to follow.

Revision history for this message
In , Grey Nicholson (greytheearthling) wrote :

Created an attachment (id=300351)
The BBC homepage beta in Firefox 2

This page renders correctly in Firefox 2 (aside from the black box around the Flash clock).

Revision history for this message
In , Grey Nicholson (greytheearthling) wrote :

Created an attachment (id=300352)
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.

Revision history for this message
In , Grey Nicholson (greytheearthling) wrote :

Created an attachment (id=300358)
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.

Revision history for this message
In , Grey Nicholson (greytheearthling) wrote :

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.

Revision history for this message
In , Γριφεγ (grfgguvf) wrote :

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.

Revision history for this message
In , Thoughtcube (thoughtcube) wrote :

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.

Revision history for this message
In , Grey Nicholson (greytheearthling) wrote :

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

Revision history for this message
In , Thoughtcube (thoughtcube) wrote :

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

Revision history for this message
In , Γριφεγ (grfgguvf) wrote :

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.

Revision history for this message
kripken (kripkenstein) wrote :

Is anything in particular missing because of which this report is 'incomplete'?

Revision history for this message
Grey Nicholson (greytheearthling) wrote :

There are more details and screenshots at https://bugzilla.mozilla.org/show_bug.cgi?id=411831

Revision history for this message
Grey Nicholson (greytheearthling) wrote :

I can also reproduce this on Feisty using a Firefox trunk build from Mozilla. Presumably Gutsy is affected too.

Revision history for this message
Grey Nicholson (greytheearthling) wrote :

In Gutsy, images that fail to appear at all in Feisty and Hardy (for example: the tabs at https://help.ubuntu.com and the border around “Customise homepage” at http://www.bbc.co.uk/home/beta/ ) *are* drawn, but much too light—as if the opaque parts of the image had been overlaid with semi-transparent white.

Revision history for this message
Alexander Sack (asac) wrote :

this issue is incomplete for firefox-3.0 until we know that this is a firefox bug.

Alexander Sack (asac)
Changed in xorg-server:
milestone: none → ubuntu-8.04-beta
Changed in firefox-3.0:
milestone: none → ubuntu-8.04-beta
Alexander Sack (asac)
Changed in xulrunner-1.9:
status: New → Confirmed
Changed in firefox-3.0:
status: Incomplete → Invalid
Alexander Sack (asac)
Changed in xulrunner-1.9:
importance: Undecided → Medium
milestone: none → ubuntu-8.04
Changed in xorg-server:
importance: Undecided → Medium
Changed in xulrunner:
status: Unknown → Confirmed
Changed in xorg-server:
status: Unknown → Confirmed
Alexander Sack (asac)
Changed in xulrunner-1.9:
status: Confirmed → Triaged
Changed in epiphany-browser:
status: New → Invalid
Martin Pitt (pitti)
Changed in firefox-3.0:
milestone: ubuntu-8.04-beta → none
Steve Langasek (vorlon)
Changed in xorg-server:
milestone: ubuntu-8.04-beta → ubuntu-8.04
Alexander Sack (asac)
Changed in xulrunner-1.9:
assignee: nobody → asac
Changed in firefox-3.0:
assignee: nobody → asac
Alexander Sack (asac)
Changed in xulrunner-1.9:
status: Triaged → Fix Committed
Colin Watson (cjwatson)
Changed in xorg-server:
assignee: nobody → bryceharrington
Alexander Sack (asac)
description: updated
Changed in xulrunner-1.9:
status: Fix Committed → Fix Released
Bryce Harrington (bryce)
Changed in xorg-server:
status: Confirmed → Fix Committed
Changed in xorg-server:
status: Fix Committed → Fix Released
Alexander Sack (asac)
Changed in xorg-server:
status: Fix Released → Triaged
status: Triaged → Fix Committed
Changed in xorg-server:
status: Fix Committed → Fix Released
Saša Bodiroža (jazzva)
Changed in imagezoom:
status: New → Invalid
Changed in firefox:
status: Unknown → Confirmed
Changed in firefox:
status: Confirmed → Invalid
Changed in xulrunner:
status: Confirmed → Invalid
194 comments hidden view all 274 comments
Revision history for this message
In , xenoterracide (xenoterracide) wrote :

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

Revision history for this message
In , Luke-hutchison (luke-hutchison) wrote :

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)

Revision history for this message
In , Γριφεγ (grfgguvf) wrote :

Created an attachment (id=321823)
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

Revision history for this message
In , Luke-hutchison (luke-hutchison) wrote :

Created an attachment (id=321843)
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.

Revision history for this message
In , Luke-hutchison (luke-hutchison) wrote :

Created an attachment (id=321844)
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.

Revision history for this message
In , Luke-hutchison (luke-hutchison) wrote :

PS you can also see the black box problem by opening the image in attachment 321843 directly in FF3, and then holding Ctrl while rolling the mousewheel to zoom in and out.

Revision history for this message
In , Chris Sherlock (ta-bu-shi-da-yu) wrote :

The xorg bug is actually at this address:

https://bugs.freedesktop.org/show_bug.cgi?id=15098

Revision history for this message
In , Luke-hutchison (luke-hutchison) wrote :

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...

Revision history for this message
In , Luke-hutchison (luke-hutchison) wrote :

Created an attachment (id=321964)
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.

Revision history for this message
In , Luke-hutchison (luke-hutchison) wrote :

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.

Revision history for this message
In , Richard-coe (richard-coe) wrote :

I changed from using fglrx to radeonhd to fix another issue, and I can't
reproduce the problem on my platform.

Revision history for this message
In , Rajeev V. Pillai (rajeev-v-pillai) wrote :

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+

Revision history for this message
In , Mateo-mmatachana (mateo-mmatachana) wrote :

*** Bug 437428 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

*** Bug 439109 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Dstile (dstile) wrote :

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?

Revision history for this message
In , William Maddler (news-maddler) wrote :

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)

Revision history for this message
In , Eugaia-hotmail (eugaia-hotmail) wrote :

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.

Revision history for this message
In , moenchmeyer (rm-anracon) wrote :

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

Revision history for this message
In , Ryanvm (ryanvm) wrote :

This bug has nothing to do with image scaling quality. The bug for that is bug 422179.

Revision history for this message
In , Chris Sherlock (ta-bu-shi-da-yu) wrote :

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 arsed 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."

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

*** Bug 441181 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Alexander Sack (asac) wrote :

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

Revision history for this message
Lee (deth) wrote :

I have this problem with an oddly-sized GIF image (attached) - it's supposed to have transparency under it, which gimp shows but display (from ImageMagick) does not... indicating that it's got a height change rather than true transparency. In my case, the black area shows where the transparency is supposed to be - beneath the button.

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

*** Bug 441369 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

*** Bug 450097 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Kevin Brosnan (kbrosnan) wrote :

*** Bug 440518 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Havar-firefox (havar-firefox) wrote :

*** Bug 457575 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

*** Bug 442451 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

*** Bug 470724 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

*** Bug 472564 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Nick Welch (mackstann) wrote :

*** Bug 472472 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

*** Bug 473130 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Alexander Sack (asac) wrote :

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.

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

*** Bug 477292 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Kevin Brosnan (kbrosnan) wrote :

*** Bug 497220 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Richard-2009 (richard-2009) wrote :

*** Bug 502455 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Richard-2009 (richard-2009) wrote :

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"

Changed in xorg-server:
status: Confirmed → Fix Released
Revision history for this message
Dan Dascalescu (ddascalescu+launchpad) wrote :

I know I'm jumping in late, but I see this behavior (black images) as of Firefox 3.5.6 on Windows XP SP3 (native, no virtualization).

Images become black more often as the number of tabs increases. Special culprits are Wikipedia and OKCupid. Rebooting the machine fixes the problem, so this smells more like a memory leak in the already bloated Firefox.

Revision history for this message
In , Kevin Brosnan (kbrosnan) wrote :

*** Bug 485694 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Geeknik (geeknik) wrote :

*** Bug 418826 has been marked as a duplicate of this bug. ***

Changed in firefox:
importance: Unknown → High
Changed in xulrunner:
importance: Unknown → High
Changed in xorg-server:
importance: Unknown → Critical
Changed in xorg-server:
importance: Critical → Unknown
Changed in xorg-server:
importance: Unknown → Critical
Displaying first 40 and last 40 comments. View all 274 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.