Closed Bug 334951 Opened 18 years ago Closed 18 years ago

Resized image displayed as black rectangle

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: dennisml, Unassigned)

References

(
URL
)

Details

(Keywords: testcase, Whiteboard: [upstream problem with X; see https://launchpad.net/distros/ubuntu/+source/xorg-server/+bug/49684 for more info])

Attachments

(2 files)

Partial screenshot of the URL submitted with the bug
58.23 KB, image/png
Details
testcase
499 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060420 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060420 Minefield/3.0a1

Some images that appear in a page and use width and/or height attributes that are smaller than the actual image are only displayed as black rectangles. Selecting "Vie Image" from the context menu displays the image just fine in it's original size.

Reproducible: Sometimes

Steps to Reproduce:
1. Go to the URL submitted with this bug 

Actual Results:  
The first image in the middle column where the article is displayed is just a black rectangle.

Expected Results:  
The image is displayed properly.

Fedora Core Rawhide system:
gtk2-2.8.17-2
cairo-1.0.4-1
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a1) Gecko/20060421 Minefield/3.0a1 - Build ID: 0000000000
WFM.
Just updated to Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060421 Minefield/3.0a1 but I'm still seeing this.
What are your build settings? Mine are as follows:
. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/fx-opt-dynamic
ac_add_options --disable-optimize
ac_add_options --enable-tests
ac_add_options --enable-xpctools
ac_add_options --enable-timeline
ac_add_options --enable-reflow-perf
ac_add_options --enable-perf-metrics
ac_add_options --enable-debug
ac_add_options --disable-strip
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --enable-pango
ac_add_options --enable-places
ac_add_options --enable-xft
ac_add_options --enable-canvas
ac_add_options --enable-mathml
ac_add_options --enable-svg
ac_add_options --enable-svg-renderer=cairo
mk_add_options MOZ_CO_PROJECT=browser
I'm using the regular nightly builds. This is what about:buildconfig says:

--enable-application=browser
--enable-update-channel=nightly
--enable-update-packaging
--enable-optimize
--disable-debug
--disable-tests
--enable-canvas
--enable-svg
--enable-pango
--enable-default-toolkit=cairo-gtk2
--enable-static
--disable-shared
--enable-codesighs

One thing I've noticed with the latest builds is that images which haven't loaded yet are black squares, with the area gradually being filled up as the image loads. Perhaps this is the problem? That the image isn't loading?
No, selecting "View Image" from the context menu displays the image fine. This also only happens with some images, others are displayed ok even when resized.
I'm seeing this as well (SeaMonkey cairo build from yesterday), but the image shows up white instead of black.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Attached file testcase — 
first image (unscaled) displays ok, second one (scaled) displays white.

A third one in a blue div shows up blue, so I'm apparently getting a transparent or not-drawn-at-all image.
Actually it seems the image doesn't just show up black for me but in some cases it shows up random parts of my desktop or parts of images used on webpages I visited a minute before. It looks like the memory address of the image to display calculated wrongly and random bits of the X servers pixmem are shown.
Flags: blocking1.9a1?
*** Bug 335990 has been marked as a duplicate of this bug. ***
This seems to be a bug in the latest Xorg 7.1 RC releases. Applying the patch in the following Xorg bug fixes this problem for me:
https://bugs.freedesktop.org/show_bug.cgi?id=6827

OK. Resolving as INVALID then. :)
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
I don't think this should be counted as invalid until we actually
see this fixed with a new version of xorg.  For one thing, the
symptoms described in this bug are not exactly the same as those
described in the duplicate I reported, Bug 335990.  I see no black
rectangles.  I see nothing: a white background when the page is
white.

For another, that bug is not found in pre-canvas Firefox, so it is not just in xorg.

It is a fairly serious bug, since there are re-sized images all over
the place.

We haven't seen this fixed in a new version of Xorg, but Dennis says the symptoms disappear when he applies the patch to his Xorg version:
> This seems to be a bug in the latest Xorg 7.1 RC releases. Applying the patch
> in the following Xorg bug fixes this problem for me:
> https://bugs.freedesktop.org/show_bug.cgi?id=6827


The discussion for the Xorg bug I mentioned above has evolved a bit and the patch only seems to address certain cases but not all of them. The following page still doesn't display properly: http://sinfest.net/d/20060429.html
What is interesting about this is that the image gets displayed progressively as it loads but as soon as the loading is finished all or a part (from a random row all the way down) of the image turns white.

That still WFM, but I'm not on Xorg 7, and I presume all the people who can reproduce this are.

Reopening. :-(
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
*** Bug 338521 has been marked as a duplicate of this bug. ***
The following page shows similar symptoms but for non-resized images: http://tango-project.org/Window_Experiments

This page also creates major performance problems for me which seem to be related to this bug. Moving a window in front of a Firefox window displaying this page slows down dramatically as soon as parts of any of the images in the page are exposed (ie are no longer hidden behind the moving window). 
This bug is not present on an identical Firefox setup on a new
computer.  (I copied the profile.)  The difference is that the
new computer has a fresh install of Fedora Core 5 rather than an
update (so that it may have something that the old one doesn't
have), AND the new one is 64 bit (x86_64).  It also has a
different video, etc. (and otherwise has major problems).
The bug is still present in the Gecko 20060522 version of Firefox
on the old computer.

(In reply to comment #19)
> This bug is not present on an identical Firefox setup on a new
> computer.  (I copied the profile.)  The difference is 
> [...] the new one is 64 bit (x86_64).

From reading the comments it seems that the problem is reproducible only on 32 bit x86 platform with Linux/X.org. This bug shouldn't be closed just because testcase works on x86_64.

Firefox 1.5.0.3 doesn't have any problems with the testcase while running on X.org. There might be something wrong with the X server but this is a regression. As this doesn't happen with ALL jpeg images (only with images with progressive encoding or with height of (2*N)+1 pixels?) I'd guess there's something more than just the X server issue going on.

(In reply to comment #20)
> Firefox 1.5.0.3 doesn't have any problems with the testcase while running on
> X.org. There might be something wrong with the X server but this is a
> regression. As this doesn't happen with ALL jpeg images (only with images with
> progressive encoding or with height of (2*N)+1 pixels?) I'd guess there's
> something more than just the X server issue going on.

Right.  It may have to do with cairo, which is used in the trunk
now but not in Firefox 1.5.x.  But it is not necessarily in cairo
alone.

This seems to be a driver issue. I replaced my Geforce 2 MX with a Radeon 9500pro and switched from the "nv" driver to "radeon" and the problem disappeared.
(In reply to comment #22)
> This seems to be a driver issue. I replaced my Geforce 2 MX with a Radeon
> 9500pro and switched from the "nv" driver to "radeon" and the problem
> disappeared.

Yes, but it isn't just the driver.  It is that interacting with something else.  Before cairo this was not a problem with the nv
driver.  That is, by the way, the same one I had when I noticed
the problem.  I had thought it had something to do with 32 bit
vs. 64 bit, but my 64-bit computer also has a different driver
(with major problems, but not this problem: i810).

I was experiencing similar problems in openoffice on Xgl server. The problem was in cairo not clipping some render operations, so I had to add some more explicit clipping for images paints.

Newer (unstable) versions of cairo helped with that, so it might be worth to check if the bug goes away with unstable snaphots of cairo. If so, additional clipping around image paints might help you too.
(In reply to comment #24)
> Newer (unstable) versions of cairo helped with that, so it might be worth to
> check if the bug goes away with unstable snaphots of cairo. If so, additional
> clipping around image paints might help you too.

This isn't just one person's problem.  Probably 10% of the images on the web
are resized, e.g., using "width" as part of <img ...>.  But I did just try
the latest development version of cairo that I could find (1.1.6-6 from
the Fedora development repository), and it didn't solve the problem.
Is there a later version to try?  Where did you get it?

mozilla doesn't usually use the system cairo...
This bug may be fixed as of 6/13/2006.  (There was a recent
check-in concerning cairo, which might have fixed it.  I cannot
find that now.)

However, at the same time I changed my driver from radeon to fglrx.
So it may still be a driver-specific issue.

Someone else should test it before it is marked as fixed.

*** Bug 341281 has been marked as a duplicate of this bug. ***
WFM with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060613 Minefield/3.0a1 ID:2006061317 [cairo]. I think that this bug can be closed.
I tried out this patch and it fixed the problem for me, too. So this is obviously not a bug in Mozilla. -> INVALID
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → INVALID
Whiteboard: [upstream problem with X; see https://launchpad.net/distros/ubuntu/+source/xorg-server/+bug/49684 for more info]
Flags: blocking1.9a1?
(In reply to comment #18)
> The following page shows similar symptoms but for non-resized images:
> http://tango-project.org/Window_Experiments
> 
> This page also creates major performance problems for me which seem to be
> related to this bug. Moving a window in front of a Firefox window displaying
> this page slows down dramatically as soon as parts of any of the images in the
> page are exposed (ie are no longer hidden behind the moving window). 
> 

I'm still seeing this problem in the trunk builds but this works fine with the branch so I think this is a cairo issue that gets triggered by the nvidia driver but not by the radeon one.
Reopening.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
In hindsight the original URL filed with the bug works now and the Tango page really seems to be a different issue so I'll file a new bug for that. Back to invalid, sorry for the noise.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → INVALID
(In reply to comment #32)
> In hindsight the original URL filed with the bug works now and the Tango page
> really seems to be a different issue so I'll file a new bug for that. Back to
> invalid, sorry for the noise.
> 

Is there a new bug?  It now appears that this bug is related to bug 342083.  Although the present bug is invalid, something is still wrong, and it happens with trunk builds that use cairo and not with pre-cairo builds.  (I'm not sure that this is the critical distinction, but the point is that it isn't JUST the X server.)

I filed bug 341746 to deal with the problem with the Tango page.

For what it is worth, this bug came back when I switched from a fglrx driver to a radeon driver.  No resized images display.  I seem to be using X.Org version 7.0.0.


(In reply to comment #34)
> I filed bug 341746 to deal with the problem with the Tango page.

After looking at that, I think the present bug is different.  The Tango page displays fine for me (radeon driver).  I think the present bug should be reopened.

I'm going to summarize the situation in bug 342083.  The gist is that the present bug is still present.

I'm still seeing this bug with firefox 3 beta 3 official builds on debian sid, so it still valid?
I'm seeing this issue, and found this bug report while doing a search.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008021707 Minefield/3.0b4pre
the URL above besides many others still show this bug.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041104 Minefield/3.0pre

reopen?!
I don't see this anymore but I'm running a very recent version of Xorg and the nv driver (The one in the Fedora 9 Beta to be exact).
summary    X.Org X server -- ATI display driver
version    1:6.8.0-1

summary    X.Org X Window System
version    1:7.3+10

(debian sid)
it feels like no graphics acceleration at all.
I recently upgraded to xorg-server-1.4.0.90 and the problem is now resolved.
regardless of me annoying someone...^^

summary    Xorg X server - core server
version    2:1.4.1~git20080131-3

Xorg.log, however, says 1.4.0.90

I can still reproduce this problem.
It apparently being tracked (still listed as new) in 411831.
still present in RC1 and 2008051704

X.Org: 1:7.3+10
xserver-xorg-core: 2:1.4.1~git20080507-1
As updated in Bug 411831 ....

I've caught mozilla painting the black image

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

Something scribbling where they are not supposed to ....

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

Breakpoint 8, nsJPEGDecoder::OutputScanlines (this=0x9027800)
    at /usr/local/src/moz/cvs/mozilla/modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cpp:694
694       while ((mInfo.output_scanline < mInfo.output_height)) {
0x94e5000:      0xffffffff      0xffffffff      0xffffffff      0xffffffff
0x94e5010:      0xffffffff      0xffffffff      0xffffffff      0xffffffff

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 image will appear in a drag window.
In the code below, the first if-statement is never executed because mFrame
is the opaque object 'nsnull'.  I'm not sure what do_CreateInstance
returns in a failure case, but appears based on usage 'NULL'.

modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cpp
 470     mImage->GetFrameAt(0, getter_AddRefs(mFrame));
 471 
 472     PRBool createNewFrame = PR_TRUE;
 473
 474     if (mFrame) {
[...]
 485     } 
[...]
 489       if (!mFrame) {




Does anyone agree that it is a problem that mozilla-FF has it's own cairo/pixman
libraries and headers and it also depends on the system libcairo ??

ldd firefox-bin | egrep libcairo
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb793a000)
libgdk-x11-2.0.so :::
 0x00000001 (NEEDED)                     Shared library: [libcairo.so.2]
libgtk-x11-2.0.so :::
 0x00000001 (NEEDED)                     Shared library: [libcairo.so.2]
libxul.so :::
 0x00000001 (NEEDED)                     Shared library: [libcairo.so.2]

I changed from using fglrx to radeonhd to fix another issue, and I can't 
reproduce the problem on my platform.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: