Black rectangle instead of image in FF3 [Hardy]

[kripken]

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.

[Γριφεγ (grfgguvf)]

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

[Γριφεγ (grfgguvf)]

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

[Γριφεγ (grfgguvf)]

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)

[kripken (kripkenstein)]

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.

[kripken (kripkenstein)]

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,

[Mb (mb-deactivatedaccount-deactivatedaccount-deactivatedaccount)]

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

[kripken (kripkenstein)]

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

[Mb (mb-deactivatedaccount-deactivatedaccount-deactivatedaccount)]

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

[Nanley Chery (nanoman)]

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

[kripken (kripkenstein)]

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.

[kripken (kripkenstein)]

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

[kripken (kripkenstein)]

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

[Nanley Chery (nanoman)]

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

[sojourner (itsmealso2)]

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

[Alexander Sack (asac)]

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

Thanks,
 - Alexander

[kripken (kripkenstein)]

Here is an example image.

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

[Alexander Sack (asac)]

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

[kripken (kripkenstein)]

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.

[Alexander Sack (asac)]

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

[kripken (kripkenstein)]

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

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

[Grey Nicholson (greytheearthling)]

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.

[Grey Nicholson (greytheearthling)]

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.

[Grey Nicholson (greytheearthling)]

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.

[Grey Nicholson (greytheearthling)]

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

[Grey Nicholson (greytheearthling)]

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.

[Grey Nicholson (greytheearthling)]

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

[Grey Nicholson (greytheearthling)]

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

[Grey Nicholson (greytheearthling)]

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.

[Grey Nicholson (greytheearthling)]

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.

[Grey Nicholson (greytheearthling)]

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.

[Γριφεγ (grfgguvf)]

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.

[Thoughtcube (thoughtcube)]

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.

[Grey Nicholson (greytheearthling)]

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

[Thoughtcube (thoughtcube)]

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

[Γριφεγ (grfgguvf)]

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.

[kripken (kripkenstein)]

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

[Grey Nicholson (greytheearthling)]

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

[Grey Nicholson (greytheearthling)]

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

[Grey Nicholson (greytheearthling)]

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.

[Alexander Sack (asac)]

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

[kripken (kripkenstein)]

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

Thanks. I just wanted to make sure that I didn't forget to attach some info here.

[Grey Nicholson (greytheearthling)]

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

Since this affects Liferea too, I think that (if anything) it'll be a bug in the Mozilla/Gecko/Xulrunner library.

[Tony Yarusso (tonyyarusso)]

I have the same symptom, with some variation on conditions:
Graphics driver: radeon
Browsers: both Firefox 3.0 and Epiphany 2.21, on Hardy
Reproducable site: http://virtualnorthstar.org/ - the large pictures of in-world views
Zoom levels: All

That makes Firefox 3, Liferea, and Epiphany all affected, with the common ground being gecko/xulrunner, so I'll second that assumption.

[a.sip (sippan)]

I'm experiencing the same thing with nv-driver. Both FF3, FF2 and liferea.

[Samuel Lidén Borell (samuellb)]

Same problem here too, but with the "ati" (open source) driver. I have a Radeon Xpress 200M graphics card which is known to not work 100% correctly, though I've never experienced any problems with 2D graphics.

There was a similar bug a couple of years ago that occurred with scaled images too. Maybe there's some useful information in it:
https://bugzilla.mozilla.org/show_bug.cgi?id=324698
(Cairo is mentioned a few times in that bug, could Cairo the the cause of this bug or can it be ruled out?)

[Damjan Georgievski (gdamjan)]

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.

[Eric Chan (chanman)]

The problem is consistently reproducible on a macbook pro running hardy with the background image of http://www.slackware.com. driver is fglrx.
Another machine running glx and a fresh install. Intel chips seem unaffected. I would imagine that this has to do with a mismatch in where the image is stored and retrieved from but its purely speculation.

[Egon Kocjan (egon-kocjan)]

Reproducible on Hardy with ati driver (on R250 mobile radeon) on this page:
http://flors.wordpress.com/2008/02/20/aesthetix-of-matrics/

[Egon Kocjan (egon-kocjan)]

Interestingly, the bug can be reproduced with midori as well. Midori uses webkit, if I'm not mistaken:

$ ldd /usr/bin/midori | grep Web
 libWebKitGtk.so.1d => /usr/lib/libWebKitGtk.so.1d (0xb7a2e000)

[Alexander Sack (asac)]

blocking beta

[Alexander Sack (asac)]

not a firefox-3.0 bug. keeping xulrunner-1.9 task instead.

[Xake (xake-rymdraket)]

I have this problems:

* Missing/misplaced pictures with black borders.
    Many times the thumbnails works, and if i show just the picture it does not show up scaled, but shows up when I zoom up to full scale. Size seems to have an aspect also as files with (maybe much) greater height then width seems to fail more often when scaled then the one with greater width.
* Backgrounds fails.
   www.vasttrafik.se often gives me my upper panel over and over again as background.

This is on updated hardy.
The computer is a P4 notebook with a sis-video chipset/driver and the standard Ubuntu configuration.

[Alexander Sack (asac)]

could somone confirm that this happens with mozilla.com builds as well?

[Grey Nicholson (greytheearthling)]

Yes, this affects Mozilla's trunk builds too (has done for several weeks). I can't discern any difference between the symptoms in Mozilla's builds versus Ubuntu's.

(By the way, this bug's title mentions just one symptom of the larger problem: “Xulrunner displays some images incorrectly (as copies of other parts of the screen or black rectangles) or not at all, especially when scaled” would be a more complete description.)

[Alexander Sack (asac)]

dupe of bug 380115 ?

[Alexander Sack (asac)]

if you see this, please test if the latest patch in there fixes your issue as well.

[Grey Nicholson (greytheearthling)]

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

[Alexander Sack (asac)]

anyone still has gutsy and could try if the mozilla.com build works there? (e.g. if its a xorg regression)?

[Samuel Lidén Borell (samuellb)]

Firefox 3 works correctly on Gutsy.

[saurabh (faplap)]

I can confirm this with Xorg 7.3 and the OSS radeon driver.

[Alexander Sack (asac)]

there is a patch in https://bugzilla.mozilla.org/show_bug.cgi?id=380115

we should try that.

[Grey Nicholson (greytheearthling)]

Samuel L. B.: I found that on Gutsy, some images were rendered too bright (washed-out, as if overlaid by a semi-opaque white) using Mozilla's Firefox 3—the tabs at https://help.ubuntu.com/ are an example.

[Samuel Lidén Borell (samuellb)]

Greg: That page works flawlessly on Gutsy for me. What driver are you using?

[Grey Nicholson (greytheearthling)]

I'm not sure: System → Administration → Hardware Drivers shows “NVIDIA accelerated graphics driver (legacy cards)”, but that's “Not in use”. (Besides which, I've now upgraded to Hardy.)

Also, in the System Monitor's Resources tab on Hardy, the graphs' backgrounds are black and the plots leave traces as they move (though only when the window is somewhat wider than the minimum)—is that this bug or a separate one?

[Adi Roiban (adiroiban)]

I have the same problem with open source drivers of Ati Radeon X300 video board.

It is not only a nvidia bug

[Samuel Lidén Borell (samuellb)]

It appears that this bug occurs when images are either stretched/zoomed or tiled (repeated). Also, it only seems to appear with large images. On my computer images of sizes of 253x253 pixels are affected, but images of 253x252 pixels are not.

I've attached a test case so you can try for yourself and see if the images break at the same sizes.

[Egon Kocjan (egon-kocjan)]

I get the same result - 253x252 is ok, others are not.

[Robert-manamind (robert-manamind)]

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-manamind (robert-manamind)]

Created an attachment (id=307228)
Transparent GIF, renders correctly

[Robert-manamind (robert-manamind)]

Created an attachment (id=307229)
Transparent GIF, renders incorrect as invisible

[saurabh (faplap)]

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.

[Robert-manamind (robert-manamind)]

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

[mabovo (mabovo)]

I get an strange behavior when openning images to zoomming them in outside browser diverse from FF2.
For example, using FF2 it opens normally but on FF3 image zoom don't open widely.
See sample at http://www.autoxtreme.com.br/product_info.php?products_id=967 and try to zomm picture of DXZ369MP product.

[Alexander Sack (asac)]

This appears to be not an upstream issue because of the libjpeg they ship in the mozilla source. Unfortunately, they carry quite a few ancient patches that are not reasonably documented.

If we cannot find a feasible cherry-pick for this bug we should consider to just drop the system-jpeg configure switch.

If anyone volunteers to dig into this I can provide you with pointers to get started.

Ping me in #ubuntu-mozillateam on irc.freenode (asac).

Thanks,
 - Alexander

[Alexander Sack (asac)]

nothing epiphany related ... invalidating the epiphay-browser task accordingly.

[Gordon Hopper (gohopper)]

The best work-around is to press Ctrl-0 to reset the zoom.

Appears to be related to the size of the image, not to the image format. I converted the format of several images between jpg, png, and gif, and the same image sizes caused issues with all 3 formats. (Though in some cases the offset was different.)

Here are some image sizes with issues:
705x99
720x350
500x500
253x253

[Gordon Hopper (gohopper)]

Attached is a (crude) test script. (Place it on a php5 enabled web server). Things start to get interesting around the page marked 250. 253x253 is the smallest square image that exhibits the behavior.

[Gordon Hopper (gohopper)]

Attached is a screenshot of the above test script on the 250 page. (Press ctrl-- to zoom out). Images where height+width is > 507 might have this issue.

[Xake (xake-rymdraket)]

Is it time for someone to clearify things so we do not get more bugspam?

This bug has nothing to do with the size or format of your images. That is just symptoms.
The bugs is a xorg bug (linked at the top of this page, "RenderComposite with XAA renders at wrong position if vertically scaled.").

So a "easy" workaround is making your driver use EXA (if it supports it) or hope for a fix to xorg soon.
Me myself seems to have to wait, since the sis videodriver supports EXA but kills X when it is enabled in funny ways.

[Caroline Ford (secretlondon)]

I suspect bug #202393 and this are related. That bug is [Firefox 3.0b4 in Hardy alpha 6] some png pictures are not displayed on web pages after a zoom in.

[Caroline Ford (secretlondon)]

Reading the upstream bug I've made the missing PNG bug a duplicate of this one. It's unconnected to zoom levels (despite the title) and I have on trident too (so not an nv thing).

[antistress (antistress)]

(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

[antistress (antistress)]

i'm the one who filled the duplicate bug #202393 and i have a radeon 8500 with default (free) driver

[Bryanbach (bryanbach)]

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

[Miso (m-krauth)]

Making my driver use EXA didn't work immediately for me.

I had to add another line in "Device" section of xorg.conf to make it work :

Option "AccelMethod" "EXA"
Option "MigrationHeuristic" "greedy"

[Matti-mversen (matti-mversen)]

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

[Dmitry Potapov (dpotapov)]

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

[Jes-martnet (jes-martnet)]

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?

[Dmitry Potapov (dpotapov)]

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

[Vladimir Vukicevic (vvuk)]

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.

[Matti-mversen (matti-mversen)]

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"

[Vladimir Vukicevic (vvuk)]

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.

[Matti-mversen (matti-mversen)]

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

[Jes-martnet (jes-martnet)]

Adding "EXA" and "MigrationHeuristic" "greedy" options together had no effect.

Adding "XAANoOffscreenPixmaps" alone fixes this for my system.

Nice!

[Vladimir Vukicevic (vvuk)]

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.

[Michael Rooney (mrooney)]

I can confirm this today on a fresh Hardy Beta install. Some people seem to be listing video drivers so I am using whatever is used by default for an ATI R350 card. Thanks!

[Bryce Harrington (bryce)]

Miso, are you using the -intel driver? If so, "greedy" should be on by default now when EXA is used (which I believe should now be all the time, unless configured differently in xorg.conf).

For users of -ati or -nv, I'd be interested in hearing if setting Option "AccelMethod" "EXA" makes the issue go away or not.

For background, Xorg is trying to move away from XAA in favor of EXA, and in general is not investing time into XAA-specific bugs. Unfortunately, that does not mean EXA is problem-free... but at least they respond to bug reports about it. For -intel we've cleared enough of the EXA bugs that we can ship that on by default in Hardy. For -ati and -nv I'm less sure what the situation is, but here too the long term objective is to move to EXA as the solution for these problems.

I don't know if Option "MigrationHeuristic" "greedy" is particular to the -intel driver, or is applicable to -ati and/or -nv, but if it is, it's something we could certainly consider forcing on, as we did for -intel. We found for Hardy that "greedy" solved a lot of different problems (particularly around performance), but I'm not sure if it's available for -ati and -nv. If it is, then it definitely would be something we could patch in, if people can validate it solves the problem.

[Xake (xake-rymdraket)]

So this is either a "live with it" or try to find out why -sis crashes my
xorg with EXA?

[kripken (kripkenstein)]

Bryce,

AccelMethod EXA with the "nv" driver does not fix this issue for me. Still black rectangles at non-default zooms.

[Egon Kocjan (egon-kocjan)]

I switched to EXA, and I cannot reproduce the bug anymore on any test image. I have radeon ("ati") - rv250 chip.

[Bryce Harrington (bryce)]

@Egon, thanks. For Hardy it's probably too intrusive to force all -ati users over to EXA but perhaps I can do it case by case. For this I'll need your card's exact pci id. Can you please attach the output of `lspci -vvnn`?

@kripkenstein, can you doublecheck /var/log/Xorg.0.log that EXA is on, and did not get disabled? (Or just attach /var/log/Xorg.0.log here).

@Xake, fwiw I've found upstream disinterested in XAA bugs, so focusing on the EXA issues would be the best course of action for you to take. Unfortunately since -sis is not as actively maintained as other drivers, this may not be easy. I would encourage you to file your bug in the upstream -sis bug tracker, and make sure to include a backtrace, your Xorg.0.log, and a detailed description of the problem.

[Victor Osadci (victor-os)]

Bryce, I tried to use EXA on a Ati X1350 with the radeon driver, and while it fixed the black images, it has drawing bugs in other parts of the desktop and is visibly slow at drawing.

Here is the output from lspci -vvnn:

01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Unknown device [1002:7196] (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company Unknown device [103c:30d7]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 10
 Region 0: Memory at d0000000 (32-bit, prefetchable) [size=128M]
 Region 1: I/O ports at 4000 [size=256]
 Region 2: Memory at dc400000 (32-bit, non-prefetchable) [size=64K]
 [virtual] Expansion ROM at dc420000 [disabled] [size=128K]
 Capabilities: [50] Power Management version 2
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Capabilities: [58] Express Legacy Endpoint IRQ 0
  Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+
  Device: Latency L0s <4us, L1 unlimited
  Device: AtnBtn- AtnInd- PwrInd-
  Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
  Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
  Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
  Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0
  Link: Latency L0s <64ns, L1 <1us
  Link: ASPM L0s L1 Enabled RCB 64 bytes CommClk+ ExtSynch-
  Link: Speed 2.5Gb/s, Width x16
 Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
  Address: 0000000000000000 Data: 0000

[antistress (antistress)]

wow
since i'm quite new to Linux, i've made some search to understand the EXA thing
i have a R200 (ATI Radeon 8500 LE)
i'm running Ubuntu 8.04 beta (clean install of Ubuntu 8.04 alpha 6 that have been automatically upgraded to beta) with Metacity composite enabled
and i've modified my xorg.conf file...

i had :
Section "Device"
 Identifier "Configured Video Device"
EndSection

And now i have :
Section "Device"
 Identifier "Configured Video Device"
 Option "AccelMethod" "EXA"
EndSection

I can't see that bug anymore

amazing

[antistress (antistress)]

here is the result of lspci -vvnn :

01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon R200 QL [Radeon 8500 LE] [1002:514c] (prog-if 00 [VGA controller])
 Subsystem: ATI Technologies Inc Radeon 8500 [1002:013a]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 64 (2000ns min), Cache Line Size: 16 bytes
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at e8000000 (32-bit, prefetchable) [size=128M]
 Region 1: I/O ports at d000 [size=256]
 Region 2: Memory at f7ef0000 (32-bit, non-prefetchable) [size=64K]
 Expansion ROM at f7ec0000 [disabled] [size=128K]
 Capabilities: <access denied>

[Miso (m-krauth)]

Hi Bryce,

Sorry I didn't answer before. Here is a copy of my "Device" section :

Section "Device"
 Identifier "ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]"
 Boardname "ati"
 Busid "PCI:1:0:0"
 Driver "ati"
 Screen 0
 Option "MergedFB" "off"
 Option "AccelMethod" "EXA"
 Option "MigrationHeuristic" "greedy"
EndSection

Thanks

[kripken (kripkenstein)]

Bryce,

You may be right about EXA not being used on my system. My log file seems to show that. I'm not sure though so I'm attaching it here.

This is odd because my xorg.conf says to use EXA:

Section "Device"
 Identifier "Configured Video Device"
 Driver "nv"
 Option "AccelMethod" "EXA"
 Option "AddARGBVisuals" "True"
 Option "AddARGBGLXVisuals" "True"
 Option "NoLogo" "True"
EndSection

[Egon Kocjan (egon-kocjan)]

lspci:

01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] [1002:4c66] (rev 01) (prog-if 00 [VGA controller])
 Subsystem: Compaq Computer Corporation Unknown device [0e11:0860]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 128 (2000ns min), Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 10
 Region 0: Memory at 98000000 (32-bit, prefetchable) [size=128M]
 Region 1: I/O ports at 3000 [size=256]
 Region 2: Memory at 90400000 (32-bit, non-prefetchable) [size=64K]
 [virtual] Expansion ROM at 90420000 [disabled] [size=128K]
 Capabilities: [58] AGP version 2.0
  Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
  Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x4
 Capabilities: [50] Power Management version 2
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-

[Luke-hutchison (luke-hutchison)]

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

[Luke-hutchison (luke-hutchison)]

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

[Matti-mversen (matti-mversen)]

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

[Matti-mversen (matti-mversen)]

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

[David-hagood-gmail (david-hagood-gmail)]

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

[aysiu (ubuntubugzilla-psychocats)]

So people using the nv driver will just have to live with the black rectangle?

[Miso (m-krauth)]

Aysiu,

Did you try to add those two lines to the "Device" section :

Option "AccelMethod" "EXA"
Option "MigrationHeuristic" "greedy"

It worked for me (I have an ATI driver).

[snurp (s-kriewel-deactivatedaccount)]

Using the proposed fix (switching to EXA) removed the black blocks for me, but makes rendering unbearably slow. So it's not really a solution. Using the radeon driver with a FireGL V3200. Output from lspci follows:

01:00.0 VGA compatible controller [0300]: ATI Technologies Inc M24GL [Mobility FireGL V3200] [1002:3154] (rev 80) (prog-if 00 [VGA controller])
 Subsystem: IBM Unknown device [1014:0570]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0, Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at c0000000 (32-bit, prefetchable) [size=128M]
 Region 1: I/O ports at 3000 [size=256]
 Region 2: Memory at a8100000 (32-bit, non-prefetchable) [size=64K]
 [virtual] Expansion ROM at a8120000 [disabled] [size=128K]
 Capabilities: [50] Power Management version 2
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Capabilities: [58] Express Endpoint IRQ 0
  Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+
  Device: Latency L0s <256ns, L1 <4us
  Device: AtnBtn- AtnInd- PwrInd-
  Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
  Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
  Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
  Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0
  Link: Latency L0s <256ns, L1 <2us
  Link: ASPM L1 Enabled RCB 64 bytes CommClk+ ExtSynch-
  Link: Speed 2.5Gb/s, Width x16
 Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
  Address: 0000000000000000 Data: 0000

[philinux (philcb)]

If I select tools clear private data which clears the cache. Then press F5 to refresh the page the image will appear when it was previously a black rectangle.

[antistress (antistress)]

as i said above, adding Option "AccelMethod" "EXA" in my xorgconf file solved that bug

but it creates another bug (see picture attached) which disapear when i add Option "MigrationHeuristic" "greedy"

shall i fill another bug report concerning that particular bug ?

[Nikolaus Filus (nfilus)]

EXA is not the solution as EXA is painfully slow for me using free radeon driver on an ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
I know AMD published the register specs and first EXA improvements are worked on, but this takes some time until mainstream can
use it.

[Laurent Bonnaud (laurent-bonnaud)]

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

[Matti-mversen (matti-mversen)]

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

[another_sam (anothersam)]

I did a test case on
http://www.islabinaria.com/samu/firefox-3/

Black rectangle or vertical lines with Ubuntu 8.04 Beta updated until right now and ATI Mobility Radeon X1400.

[Tomas Lauridsen (trol)]

I am running an updated Ubuntu 8.04 Beta as well.

At your test page the test pictures works fine, but your screen dump does not scale on my PC.

FYI:

from xorg.conf:
Section "Device"
        Identifier "ATI Technologies Inc Radeon R250 [Mobility FireGL 9000]
"
        Driver "ati"
        BusID "PCI:1:0:0"
EndSection

from lspci:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] SiS645DX Host & Memory & AGP Controller
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP)
..
..
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 01)

[Alexander Sack (asac)]

i switched to in-source jpeg in xulrunner bzr now. This should workaround this problem.

[another_sam (anothersam)]

Tomas, I made the screenshoot with ubuntu's "take a screenshot" feature and then I saved at 60% quality jpeg with kolourpaint. Maybe this is significant.

I added my equivalent info at http://www.islabinaria.com/samu/firefox-3/#system-information

I don't know if
'''Section "Device"
    Identifier "Configured Video Device"
EndSection'''
helps or it's meaningless. my knowledge about xorg.conf is quite poor.

How can I "switch to in-source jpeg"?

[Forlong (forlong)]

I just noticed a funny thing: when I boot into Ubuntu without Compiz enabled, I have the scaled black pictures.

But when I start Compiz, the issue is gone. And if I stop Compiz again, the issue is not coming back.

[Evan Carroll (evancarroll)]

I just wanted to add, I can confirm this bug also applies with the i810 driver if it is driver specific.

[Dave Hall (skwashd)]

This is still a problem with firefox 3.0b4 on i386 with "ati" driver. I am mostly noticing it with PNGs, but I haven't investigated it too much. No compiz - well since Hardy alpha 5 :(

[Mozilla-quikbox (mozilla-quikbox)]

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

[Nikolaus Filus (nfilus)]

report is marked as "fix committed" for 3 days now, but there was still no new upload of xulrunner (since 2008-03-13).
Do we need to ping someone in order to get the upload done?

[Forlong (forlong)]

The fix is committed, not released.

You can give the above mentioned bzr branch a try and report back if it works for you, if you want to help fix this bug for everyone.

[Alexander Sack (asac)]

the fix we committed partially fixes this. If you still see this after next xulrunner upload, please set

 Option "XAANoOffscreenPixmaps" "true"

in your xorg.conf device section.

[Bryce Harrington (bryce)]

I can confirm that adding Option "XAANoOffscreenPixmaps" "true" resolves the black image problem.

I still have unease about setting this as a default for everyone, though. Typically when setting these sorts of options on for everyone, a lot of corner cases turn up within 1-2 weeks after about random side effects. If we had another month of testing I'd be less uneasy. I would much prefer to see an upstream patch to solve this, than to hack in hardcoding of this parameter...

So, does anyone know of an upstream patch that solves this more properly?

[Michael Rooney (mrooney)]

Bryce, since using Compiz seems to fix the issue, can we look into what that is doing? Is it the image plugins? Perhaps this could be useful...

[antistress (antistress)]

from my comment 62, Compiz has nothing to do for me (with my ATI R200 i've switched to EXA + greedy + Metacity with composite and i can't see that bug anymore)

[Launchpad Janitor (janitor)]

This bug was fixed in the package xulrunner-1.9 - 1.9~b5+nobinonly-0ubuntu1

---------------
xulrunner-1.9 (1.9~b5+nobinonly-0ubuntu1) hardy; urgency=low

  [ Fabien Tassin <email address hidden> ]
  * Drop patch applied upstream
    - drop debian/patches/bz333308_attXXXX_make_clean_cleaner.patch
    - update debian/patches/series
  * Set LDFLAGS so dpkg-buildpackage doesn't use -Wl,-Bsymbolic-functions
    - update debian/rules
  * Add support for a defaults/syspref directory containing system wide
    preferences that will not be silently overwritten at each upgrade
    (LP: #207281, #203538).
    It works for both libxul apps such as firefox 3 and xulrunner
    applications such as prism
    - add debian/patches/add_syspref_dir.patch
    - update debian/patches/series
  * Fix broken RSS subscription
    - add debian/patches/bz423060_att312807_fix_rss_subscription.patch
    - update debian/patches/series
  * Bump depends to libnspr4-dev >= 4.7.1~beta2 and libnss3-dev >= 3.12.0~beta3
    - update update debian/control
  * Hook up mozilla-devscript's compare module to binary-post-install
    - update debian/rules

  [ Alexander Sack <email address hidden> ]
  * switch to in-source jpeg to fix rendering issues at zoom levels
    (LP: #182038); this measure should give us some performance
    improvements.
    - update debian/rules
  * make pref extensions read defaults/autoconfig from NS_GRE_DIR instead
    of NS_APP_DEFAULTS_50_DIR. If it turns out to be a bad decision, we should
    reconsider this patch.
    - add debian/patches/bzXXX_autoconfig_in_gre.patch
    - update debian/patches/series
  * install system-greprefs in /etc/xulrunner-1.9/ and create the proper
    link in $pkglibdir/greprefs to it (LP: #139543)
    - add debian/system-greprefs.js
    - update debian/rules
  * ship versioned link libsqlite3.so.0 => libsqlite3.so in $pkglibdir to
    allow liferea workaround for LP: #203413 - "Liferea creates many corrupt
    copies of places.sqlite in" by setting LD_LIBRARY_PATH properly
    - update debian/rules
  * ship .autoreg file in pkglibdir to allow autoreg touches by
    plugins/extensions et al.
    - update debian/rules
  * touch .autoreg in xulrunner-1.9.postinst and
    xulrunner-1.9-gnome-support.postinst
    - update debian/xulrunner-1.9.postinst
    - add debian/xulrunner-1.9-gnome-support.postinst
  * hook in lp-export-xpi.mk from mozilla-devscript to export en-US
    translation templates to debian/lp-export-xpis/; in turn, make
    mozilla-devscripts a hard build-depends
    - update debian/rules
    - update debian/control
  * consider NS_GRE_DIR/.autoreg to trigger component registry upgrades.
    - add debian/patches/bzXXX_gre_autoreg.patch
    - update debian/control/series
  * Fix "Dom Inspector not compatible" by bumping maxVersion field in
    extension install.rdf
    - add debian/patches/inspector_maxversion_bump.patch
    - update debian/patches/series
  * Fix xulrunner side for bug "firefox needs restart after plugin install to
    detect and activate them"; we scan for new plugins in GRE at startup runtime
    - update debian/patches/bzXXX_gre_extension_plugin_support.patch

 -- Fabien Tassin <email address hidden> ...

[Alexander Sack (asac)]

maybe there is a hacky way to workaround this in cairo somehow?

[gpothier (gpothier)]

The new xulrunner-1.9 (1.9~b5+nobinonly-0ubuntu1) does not solve the problem for me.
I have a fully updated kubuntu hardy, with firefox b5.
Video board is: ATI Technologies Inc M24 1P [Radeon Mobility X600], driver is ati r300
I'm not using compiz or any other compositing WM.
Test case: http://virtualnorthstar.org/. Two images appear fully black

[Conn O Griofa (psyke83)]

I was suffering from this issue, but xulrunner-1.9 (1.9~b5+nobinonly-0ubuntu1) did indeed fix the issue. All images display from: http://virtualnorthstar.org

gpothier,

I am using an Intel 855gm chipset, and as far as I know the "intel" driver is now forcing the "greedy" MigrationHeuristic with EXA. You should try setting that for your ati card and see if it makes a difference:

Section "Device"
 Identifier "Configured Video Device"
 Option "AccelMethod" "exa"
 Option "MigrationHeuristic" "greedy"
EndSection

[Alexander Sack (asac)]

On Sun, Apr 06, 2008 at 02:50:27AM -0000, Conn wrote:
> I was suffering from this issue, but xulrunner-1.9 (1.9~b5+nobinonly-
> 0ubuntu1) did indeed fix the issue. All images display from:
> http://virtualnorthstar.org

As I said in a previous message, this only fixes the issue partially
(read: for some setups), try disable offscreen pixmaps for xaa (like i
stated above) if you still see this.

 - Alexander

[Chris Sherlock (ta-bu-shi-da-yu)]

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?

[Chris Sherlock (ta-bu-shi-da-yu)]

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.

[Damjan Georgievski (gdamjan)]

Chris, if you read the comments you'll see it occurs with Intel and Nvidia graphic carda too.

[Konrad Paumann (kopa)]

The xulrunnerpatch didn't fix the bug for me. I had to disable the offscreen pixmaps to get rid of the bug.
Can there be any downsides in disabling this xaa option?

My Setup:
IBM Thinkpad T40 notebook
Pentium M 1.5Ghz
ATI 7500 mobile (M7)
1GB RAM
----
Hardy - fully updated
firefox-3.0~b5+nobinonly-0ubuntu1
xulrunner-1.9~b5+nobinonly-0ubuntu1

[J.Gabriels (joga)]

I confirm this behaviour with firefox on my laptop:
DELL Latitude D830
Intel T7100 @ 1.8GHz
2GB RAM
Hardy (all updates until April 5)

FF3 Beta 4, did not have this issue. It started on April 5, after the update to Beta 5.

[Matti-mversen (matti-mversen)]

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

[gpothier (gpothier)]

Yes disabling offscreen pixmaps indeed solves the issue.
I just hope it has no adverse side effects.

[Jes-martnet (jes-martnet)]

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.

[Alex (alexstrabala-deactivatedaccount)]

Problem is fixed with the following device section:

Section "Device"
 Identifier "Configured Video Device"
 Driver "fglrx"
 Option "AccelMethod" "EXA"
 Option "MigrationHeuristic" "greedy"
 Option "XAANoOffscreenPixmaps" "true"
EndSection

Specs:
Dell Inspiron E1705 (9400)
ATI Mobility Radeon X1400

All images display on http://virtualnorthstar.org.

[Matti-mversen (matti-mversen)]

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

[Chris Sherlock (ta-bu-shi-da-yu)]

I'm afraid that I'm using ffb5 also on Ubuntu, but it's not working for me.

[Luke-hutchison (luke-hutchison)]

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

[Jes-martnet (jes-martnet)]

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

[Menda (bymenda)]

Thanks! Everything is working properly adding to Section "Device":
  Option "AccelMethod" "EXA"
  Option "MigrationHeuristic" "greedy"
  Option "XAANoOffscreenPixmaps" "true"

I was getting missing/misplaced pictures with black borders at default zooming (not changing zoom).
I am using "nv" driver, Firefox 3.0 Beta 5 and Ubuntu 8.04.

[Toltech (robert-toltech)]

I see the black images also in various sites, if I copy the url of the image to its own tab and press <shift> "reload button" continuously, the the previous black image is shown, but sometimes firefox prints out: "image ..... can not be displayed because it contains errors" maybee this helps

I also don't think that changing the xorg.conf configuration file is a good solution. We deploy ubuntu on 100 of stations and can not check every one of them. For the average user it is a bummer to have a firefox which does not display all images which used to be properly displayed for many years. I find this bug, though not critical, very disturbing from a user perspective.

[Remove Me (remove-me)]

Fixed by adding just

   Option "AccelMethod" "EXA"

nothing else. Driver "radeon", for Radeon 9200 VIVO.
The card does not work smooth with EXA, though: strange delays when switching workspaces or windows (in compiz).

[Remove Me (remove-me)]

XAANoOffscreenPixmaps works too, and with less ill effects.

[Matt Saunders (matts)]

Fixed for my "nv" driver by adding only:

  Option "XAANoOffscreenPixmaps" "true"

[Chris Moore (dooglus)]

I was having this problem as soon as I upgraded from gutsy to hardy, but not before.

The problem happens whether I use the ubuntu firefox 3 package or the nightlies from mozilla.org.

The problem went away when I uninstalled the "mozilla-imagezoom" package.

I had previously tried creating a new profile, but imagezoom was automatically reinstalling itself into each new profile I made.

Is anyone having this problem without that package being installed?

[Stephen Blackheath (confectionery-kaput-stephen)]

I am using Ubuntu 8.04 beta on a PowerPC Mac PowerBook G4. Chris - I don't have "mozilla-imagezoon" package installed. This page

http://www.stuff.co.nz/689167a17217.html

has a cartoon under the banner ad. On Firefox 3.0~b5+nobinonly-0ubuntu1 this cartoon image is displaced to the top-left, showing its bottom right corner only, with the remaining area allotted to it (bottom and right) showing black.

You can view other cartoons by clicking on the thumbnails below. About a third of the time they display correctly, but reloading the page so far consistently makes them go wrong again. Occasionally the image is completely missing and all you see is a black square. Sometimes the images are correct horizontally but displaced up.

See attached screen shot.

[Stephen Blackheath (confectionery-kaput-stephen)]

I have
ii xulrunner-1.9 1.9~b5+nobinonly-0ubuntu1 XUL + XPCOM application runner
and this is the version mentioned above where Launchpad Janitor said "This bug was fixed...". It isn't fixed for me.

[Chris Moore (dooglus)]

Thanks Stephen. I just checked and it isn't fixed for me any more either. I made a new profile and visited the default mozilla.org "first run" page, and zoomed in. The image was incorrectly positioned, as before.

I also see the bug in the cartoon you linked to. Different zoom levels offset the cartoon differently, and one of the zoom levels actually displays it correctly.

I don't know if it's important, but I wasn't seeing this bug at all in gutsy, with the mozilla.org firefox nightly. Then, as soon as I switched to hardy it started happening, without changing the firefox nightly installation at all.

[Eugen Dedu (eugen-dedu)]

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.

[Eugen Dedu (eugen-dedu)]

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

[gpothier (gpothier)]

Bug still occurs with Option "XAANoOffscreenPixmaps" "true" on a fully updated Hardy. It happens a lot less than before, but I just stumbled upon it while reading this page: http://blogs.sun.com/jonathan/

In the April 1st's entry, the Glassfish image sometimes appears with a black band at the bottom. The band disappears a bit when I scroll the image in/out of view, but it usually reappears when I switch tabs.

[Alex Fraser (alex-phatcore)]

gpothier: That looks like a different bug. The top and bottom of the image* are undefined. Even if you view the image by itself with no resizing, the bottom is drawn black. The GIMP shows that the only layer is smaller than the actual image.

* https://glassfish-theme.dev.java.net/logo.gif

[Matti-mversen (matti-mversen)]

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

[Toltech (robert-toltech)]

What I don't understand is that the priority of this bug is only Unkown/Medium/Undecided.

It looks like a lot of folks have problems with firefox 3. For example I know an organisation now running gutsy which has a blog where a number of pictures turn black on Hardy FF3. I would not think of switching them to Hardy. The problem is that it is very hard to reproduce. So for me it is a critical bug.

[Matt Saunders (matts)]

I also agree that it should be a critical bug. Firefox is arguably one of the most important parts of the user experience and having this problem in it (or xulrunner) for a large minority of people could be damaging IMHO.

[Jonathan Jesse (jjesse)]

Adding my two cents here... I do not have this problem running GDM/GNOME but on my KDE 4 Kubuntu box I have this problem. I don't know how/if this matters.

Thanks,

Jonathan

[Felix Rabe (public-felixrabe)]

+1 for this bug. http://map.search.ch/ became virtually unusable with FF3 during Hardy as overlayed images displaying names / signs are not shown. I have the nv driver on an up-to-date Hardy (IA-32) installation.

[Alvin (alvevind)]

Same problem here with FF5b3.
Seems all HTML-resized images are shown as a black rectangle.

Examples where the biggest image fails when shown inside HTML:
http://viny80100.homelinux.com/galerie3.php?idimage=652
http://www.dealextreme.com/details.dx/sku.1253

[Bryce Harrington (bryce)]

Toltech, 'Unknown' is for upstream bug status, and just means the bug updater scripts couldn't figure out the upstream priority. It is 'invalid' for firefox-3.0 since the core issue was identified to be an X issue rather than firefox itself.

For X issue importance, Critical is reserved for bugs which are very widespread, prevent the user from booting/logging in to the X session, and lack an available workaround. High importance bugs are ones that result in crash/data loss, screen corruption, or other things that render some minority of systems unusable. Medium importance bugs are visual glitches or bad cosmetic issues or other things that degrade the usefulness of the computer but don't make it unusable. Low importance are cosmetic or easily worked around issues, or more serious issues that occur only extremely infrequently. So medium importance is the correct setting here.

Note that Importance != Prioritization. This bug is milestoned for 8.04 and assigned to a dev, which means it has the highest prioritization already.

Toltech, I hope this answers your question.

[Bryce Harrington (bryce)]

Patch to switch to turn off offscreen pixmaps when using XAA. This is the exact patch used by Fedora.

The XAAOffscreenPixmaps feature seems to be an early optimization trick that never really worked right; often it resulted in *worse* performance than having no optimization at all. So most distros turn it off, using a patch like this one. As extensively discussed above, the trick could also introduce some severe visual glitches, and these are resolved by switching the option off.

This patch is uploaded to the queue for release team approval.

[Bryce Harrington (bryce)]

The patch is uploaded, just waiting on release managers.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xorg-server - 2:1.4.1~git20080131-1ubuntu8

---------------
xorg-server (2:1.4.1~git20080131-1ubuntu8) hardy; urgency=low

  * 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)

 -- Bryce Harrington <email address hidden> Mon, 14 Apr 2008 12:34:54 -0700

[Alexander Sack (asac)]

ok this was apparently an accident :) the patch wasn't applied as it was not added to series. further it doesn't apply cleanly. fixed both and doing a rebuild now.

[Alexander Sack (asac)]

this one will go up if test build succeeds.

[Alexander Sack (asac)]

setting fix committed for now.

[Alexander Sack (asac)]

this is the 1.4 ported version of the patch in debdiff. (better readable this way)

[Alexander Sack (asac)]

i think its safe, but will wait for test build anyway.

[Alexander Sack (asac)]

final debdiff (verified that it works)

[Launchpad Janitor (janitor)]

This bug was fixed in the package xorg-server - 2:1.4.1~git20080131-1ubuntu9

---------------
xorg-server (2:1.4.1~git20080131-1ubuntu9) hardy; urgency=low

  * debian/patches/series,
    debian/patches/165_fedora_xserver-1.5.0-xaa-option-inversion.patch:
    - Turn on patch included in previous commit - obviously accidentially
      forgotten.
    - Now that its really enabled, make it apply to 1.4.1 code base
      accordingly. (LP: #182038)

 -- Alexander Sack <email address hidden> Tue, 15 Apr 2008 18:23:51 +0200

[Saša Bodiroža (jazzva)]

Chris Moore,

Are you still expiriencing troubles after update, with mozilla-imagezoom package installed?
By the way, when you install package of an extension it is installed for all system users, in all of their profiles.

Best regards,
Saša Bodiroža

[Toltech (robert-toltech)]

We have switched a system over from the nv to the proprietary nvidia driver. Problems seems to have been solved. Another issue with the desktop is that the screensavers were not working. In the preview they were black and the open source nv driver. Now everything is working and visible again.

Later today we will switch back again and see how the state of the system for the open source nv driver is now

[Pablo Cardozo (pcmarmol)]

With the latest update of my Ubuntu 8.04 was corrected the problem, at least
on the page that always showed me the black rectangles. Greetings! (Google
Translate) :)

On Wed, Apr 16, 2008 at 3:47 AM, Toltech <email address hidden> wrote:

> We have switched a system over from the nv to the proprietary nvidia
> driver. Problems seems to have been solved. Another issue with the
> desktop is that the screensavers were not working. In the preview they
> were black and the open source nv driver. Now everything is working and
> visible again.
>
> Later today we will switch back again and see how the state of the
> system for the open source nv driver is now
>
> --
> Black rectangle instead of image in FF3 [Hardy]
> https://bugs.launchpad.net/bugs/182038
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Usuario Linux: Nº 276696
http://counter.li.org/
http://www.flickr.com/photos/andres_hernandez/
No me envíes adjuntos en formatos NO estándar, visitá:
http://es.wikipedia.org/wiki/Formato_abierto

[Jonathan Jesse (jjesse)]

My Ubuntu box does not show this bug after the updates, but still showing
bugs on my Kubuntu box

On Wed, Apr 16, 2008 at 8:45 AM, Pablo Cardozo <email address hidden> wrote:

> With the latest update of my Ubuntu 8.04 was corrected the problem, at
> least
> on the page that always showed me the black rectangles. Greetings! (Google
> Translate) :)
>
> On Wed, Apr 16, 2008 at 3:47 AM, Toltech <email address hidden> wrote:
>
> > We have switched a system over from the nv to the proprietary nvidia
> > driver. Problems seems to have been solved. Another issue with the
> > desktop is that the screensavers were not working. In the preview they
> > were black and the open source nv driver. Now everything is working and
> > visible again.
> >
> > Later today we will switch back again and see how the state of the
> > system for the open source nv driver is now
> >
> > --
> > Black rectangle instead of image in FF3 [Hardy]
> > https://bugs.launchpad.net/bugs/182038
> > You received this bug notification because you are a direct subscriber
> > of a duplicate bug.
> >
>
>
> --
> Usuario Linux: Nº 276696
> http://counter.li.org/
> http://www.flickr.com/photos/andres_hernandez/
> No me envíes adjuntos en formatos NO estándar, visitá:
> http://es.wikipedia.org/wiki/Formato_abierto
>
>
> ** Attachment added: "unnamed"
> http://launchpadlibrarian.net/13504620/unnamed
>
> --
> Black rectangle instead of image in FF3 [Hardy]
> https://bugs.launchpad.net/bugs/182038
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Chris Sherlock (ta-bu-shi-da-yu)]

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)

[Chris Sherlock (ta-bu-shi-da-yu)]

Sorry for bug spam.

Launchpad URL:

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

[Chris Sherlock (ta-bu-shi-da-yu)]

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?

[Toltech (robert-toltech)]

I now reinstalled the open source nv driver and went to my "black rectangle test site" and things appear to be working now. Also the screen saver is working again. I will keep my system on the open source nv driver and test if the black rectangles reappear. The proprietary driver seemed to be working fine.

[Richard-coe (richard-coe)]

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.

[Saša Bodiroža (jazzva)]

Toltech, thank you for your help. I'm marking imagezoom task as invalid. If you, or anyone else, expirence the same behavior with imagezoom, please re-open the task.

[Matti-mversen (matti-mversen)]

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

[Nikolaus Filus (nfilus)]

... planet.ubuntu.com is a wonderful testsuite as I (don't) see problematic images at least once a day :)

So I still have the problem and see
 - shifted images with black borders
 - black rectangles when zoomed
 - transparent rectangle with image beeing rendered when trying to drag-and-drop

Short info:
 firefox 3.0~b5+nobinonly-0ubuntu2
 xulrunner-1.9 1.9~b5+nobinonly-0ubuntu3
 xorg 1:7.3+10ubuntu10
 xserver-xorg-core 2:1.4.1~git20080131-1ubuntu9

Section "Device"
        Identifier "Configured Video Device"
        Boardname "vesa"
        Busid "PCI:1:0:0"
        Driver "radeon" # 9700 Mobility (r300)
        Screen 0
        Option "MergedFB" "off"
        Option "XAANoOffscreenPixmaps" "true"
        Option "XaaOffscreenPixmaps" "false"
EndSection

[Egon Kocjan (egon-kocjan)]

@Bryce Harrington: I've been testing EXA for a while now and it seems to work great, performance is noticeably improved as well - scrolling complex web pages in FF works much faster now. There is one issue though, rdesktop redraws really slowly, so I had to add MigrationHeuristic option to fix it, this is the final config.:

Option "AccelMethod" "EXA"
Option "MigrationHeuristic" "greedy"

[Damjan Georgievski (gdamjan)]

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

[Sven (anders-anduras)]

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.

[Chris Sherlock (ta-bu-shi-da-yu)]

@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!

[Luke-hutchison (luke-hutchison)]

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

[Vladimir Vukicevic (vvuk)]

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.

[Damjan Georgievski (gdamjan)]

well it's a regression compared to previous Firefox versions.. I bet most people will downgrade the Firefox instead of changing their xorg.conf

[Chris Sherlock (ta-bu-shi-da-yu)]

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.

[another_sam (anothersam)]

Fixed for me by doing nothing. Just standard daily updates. I don't know exactly if this bug was resolved some days ago. These days I've been mainly offline.

I tested almost all the test cases posted on this thread and all worked! Thank you!

What about you?

My system: ATI Mobility Radeon X1400 with default drivers. Ubuntu 8.04, Release Candidate now, Beta when first posting.

[kripken (kripkenstein)]

This appears to be fixed for me as well. Been using the "nv" driver for a few days, tried problematic sites, and I have seen no issues.

[Richard-coe (richard-coe)]

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.

[Γριφεγ (grfgguvf)]

Changing title as per Chris Sherlock

[Matti-mversen (matti-mversen)]

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

[Γριφεγ (grfgguvf)]

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.

[Nikolaus Filus (nfilus)]

I just made a discovery for my case and would ask ANYONE subscribed to this bug to test it.

Browsing planet.gnome.org as usual showed almost any image either shifted or black. Then I
reset the zoom level to 0 (Ctrl+0) and from now on everything looks as expected. Afterwards
I switched "zoom text only" on. Otherwise scaling images still produces black rectangles.
For me the bug is still there - it's only not visible most the time.

[kripken (kripkenstein)]

Nikolaus: Perhaps I don't understand you, but aren't you repeating the exact description of the bug as originally filed? That is, that images are not rendered correctly at all non-default zooms, but default zoom is fine?

Currently I do not experience this issue, at any zoom, on any page I have visited.

[SammiJo (sammi-jo-fuller)]

This seems to have fixed itself for me too. I didn't have a massive problem with anything except web pages (including my own) - the black rectangles are gone when it comes to linking directly to pictures AND seeing them on webpages. Thanks, whatever you did; I'm assuming it was updates that fixed it! Roll on release!

[Nikolaus Filus (nfilus)]

kripkenstein: I wasn't sure whether "the fix" was solving the problem only for default size images or for all sizes.

Finaly I have found the cause for my problems: Disabling the two lines
        Option "XAANoOffscreenPixmaps" "true"
        Option "XaaOffscreenPixmaps" "false"
which were recommended before as a workaround fixes the issue for me for all zoom sizes.
Maybe there should be an additional fix for those who have this lines in their config?

tag: finally FIXED for me :)

[Damjan Georgievski (gdamjan)]

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

[Richard-coe (richard-coe)]

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.

[Luke-hutchison (luke-hutchison)]

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?

[Γριφεγ (grfgguvf)]

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

[Γριφεγ (grfgguvf)]

There's a good testcase in bug #334951 comment #8

[Vladimir Vukicevic (vvuk)]

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.

[Luke-hutchison (luke-hutchison)]

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.

[Richard-coe (richard-coe)]

Headline title should be
     Images (scaled, transparent) rendered incorrectly
as this problem can be reproduced independently of the
XaaNoOffscreenPixmaps setting.

[Chris Sherlock (ta-bu-shi-da-yu)]

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.

[Richard-coe (richard-coe)]

I can reproduce this problem independent of the XaaNoOffscreenPixmaps setting.
Please change the headline. Thanks.

[Tuukka Tolvanen (sp3000)]

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.

[Eugen Dedu (eugen-dedu)]

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

[Chris Sherlock (ta-bu-shi-da-yu)]

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.

[Richard-coe (richard-coe)]

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.

[Richard-coe (richard-coe)]

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.

[Richard-coe (richard-coe)]

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.

[Richard-coe (richard-coe)]

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

[Richard-coe (richard-coe)]

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

[Damjan Georgievski (gdamjan)]

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

[Luke-hutchison (luke-hutchison)]

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.

[Γριφεγ (grfgguvf)]

(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

[Richard-coe (richard-coe)]

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.

[xenoterracide (xenoterracide)]

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

[Luke-hutchison (luke-hutchison)]

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)

[Γριφεγ (grfgguvf)]

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

[Luke-hutchison (luke-hutchison)]

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.

[Luke-hutchison (luke-hutchison)]

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.

[Luke-hutchison (luke-hutchison)]

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.

[Chris Sherlock (ta-bu-shi-da-yu)]

The xorg bug is actually at this address:

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

[Luke-hutchison (luke-hutchison)]

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

[Luke-hutchison (luke-hutchison)]

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.

[Luke-hutchison (luke-hutchison)]

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.

[Richard-coe (richard-coe)]

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

[Rajeev V. Pillai (rajeev-v-pillai)]

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+

[Mateo-mmatachana (mateo-mmatachana)]

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

[Matti-mversen (matti-mversen)]

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

[Dstile (dstile)]

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?

[William Maddler (news-maddler)]

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)

[Eugaia-hotmail (eugaia-hotmail)]

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.

[moenchmeyer (rm-anracon)]

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

[Ryanvm (ryanvm)]

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

[Chris Sherlock (ta-bu-shi-da-yu)]

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

[Matti-mversen (matti-mversen)]

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

[Alexander Sack (asac)]

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

[Lee (deth)]

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.

[Timeless-bemail (timeless-bemail)]

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

[Matti-mversen (matti-mversen)]

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

[Kevin Brosnan (kbrosnan)]

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

[Havar-firefox (havar-firefox)]

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

[Matti-mversen (matti-mversen)]

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

[Matti-mversen (matti-mversen)]

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

[Matti-mversen (matti-mversen)]

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

[Nick Welch (mackstann)]

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

[Matti-mversen (matti-mversen)]

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

[Alexander Sack (asac)]

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.

[Matti-mversen (matti-mversen)]

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

[Kevin Brosnan (kbrosnan)]

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

[Richard-2009 (richard-2009)]

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

[Richard-2009 (richard-2009)]

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"

[Dan Dascalescu (ddascalescu+launchpad)]

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.

[Kevin Brosnan (kbrosnan)]

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

[Geeknik (geeknik)]

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