Closed
Bug 334951
Opened 19 years ago
Closed 19 years ago
Resized image displayed as black rectangle
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: dennisml, Unassigned)
References
()
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)
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
Comment 1•19 years ago
|
||
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a1) Gecko/20060421 Minefield/3.0a1 - Build ID: 0000000000
WFM.
Reporter | ||
Comment 2•19 years ago
|
||
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.
Comment 3•19 years ago
|
||
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
Reporter | ||
Comment 4•19 years ago
|
||
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
Comment 5•19 years ago
|
||
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?
Reporter | ||
Comment 6•19 years ago
|
||
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.
Comment 7•19 years ago
|
||
I'm seeing this as well (SeaMonkey cairo build from yesterday), but the image shows up white instead of black.
Comment 8•19 years ago
|
||
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.
Reporter | ||
Comment 9•19 years ago
|
||
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.
Reporter | ||
Updated•19 years ago
|
Flags: blocking1.9a1?
Comment 10•19 years ago
|
||
*** Bug 335990 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 11•19 years ago
|
||
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
Comment 12•19 years ago
|
||
OK. Resolving as INVALID then. :)
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Comment 13•19 years ago
|
||
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.
Comment 14•19 years ago
|
||
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
Reporter | ||
Comment 15•19 years ago
|
||
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.
Comment 16•19 years ago
|
||
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 → ---
Comment 17•19 years ago
|
||
*** Bug 338521 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 18•19 years ago
|
||
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).
Comment 19•19 years ago
|
||
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.
Comment 20•19 years ago
|
||
(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.
Comment 21•19 years ago
|
||
(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.
Reporter | ||
Comment 22•19 years ago
|
||
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.
Comment 23•19 years ago
|
||
(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).
Comment 24•19 years ago
|
||
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.
Comment 25•19 years ago
|
||
(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?
Comment 26•19 years ago
|
||
mozilla doesn't usually use the system cairo...
Comment 27•19 years ago
|
||
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.
Comment 28•19 years ago
|
||
*** Bug 341281 has been marked as a duplicate of this bug. ***
Comment 29•19 years ago
|
||
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.
Comment 30•19 years ago
|
||
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: 19 years ago → 19 years ago
Resolution: --- → INVALID
Whiteboard: [upstream problem with X; see https://launchpad.net/distros/ubuntu/+source/xorg-server/+bug/49684 for more info]
Updated•19 years ago
|
Flags: blocking1.9a1?
Reporter | ||
Comment 31•19 years ago
|
||
(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 → ---
Reporter | ||
Comment 32•19 years ago
|
||
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: 19 years ago → 19 years ago
Resolution: --- → INVALID
Comment 33•18 years ago
|
||
(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.)
Reporter | ||
Comment 34•18 years ago
|
||
I filed bug 341746 to deal with the problem with the Tango page.
Comment 35•18 years ago
|
||
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.
Comment 36•18 years ago
|
||
(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.
Comment 37•18 years ago
|
||
I'm going to summarize the situation in bug 342083. The gist is that the present bug is still present.
Comment 38•17 years ago
|
||
I'm still seeing this bug with firefox 3 beta 3 official builds on debian sid, so it still valid?
Comment 39•17 years ago
|
||
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
Comment 40•17 years ago
|
||
This url displays the issue
http://www.texasstartupblog.com/2008/02/20/venture-capital-t-shirts/
Comment 41•17 years ago
|
||
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?!
Reporter | ||
Comment 42•17 years ago
|
||
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).
Comment 43•17 years ago
|
||
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.
Comment 44•17 years ago
|
||
I recently upgraded to xorg-server-1.4.0.90 and the problem is now resolved.
Comment 45•17 years ago
|
||
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
Comment 46•17 years ago
|
||
I can still reproduce this problem.
It apparently being tracked (still listed as new) in 411831.
Comment 47•17 years ago
|
||
still present in RC1 and 2008051704
X.Org: 1:7.3+10
xserver-xorg-core: 2:1.4.1~git20080507-1
Comment 48•17 years ago
|
||
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
Comment 49•17 years ago
|
||
Something scribbling where they are not supposed to ....
Breakpoint 8, nsJPEGDecoder::OutputScanlines (this=0x9027800)
at /usr/local/src/moz/cvs/mozilla/modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cpp:694
694 while ((mInfo.output_scanline < mInfo.output_height)) {
0x94e5000: 0x73617274 0x632f3c74 0x543a7372 0x43656e6f
0x94e5010: 0x65767275 0x656d614e 0x20200a3e 0x20202020
(gdb) c
Continuing.
[Thread 0xb28dab90 (LWP 9263) exited]
Breakpoint 8, nsJPEGDecoder::OutputScanlines (this=0x9027800)
at /usr/local/src/moz/cvs/mozilla/modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cpp:694
694 while ((mInfo.output_scanline < mInfo.output_height)) {
0x94e5000: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
0x94e5010: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
Comment 50•17 years ago
|
||
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.
Comment 51•17 years ago
|
||
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) {
Comment 52•17 years ago
|
||
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]
Comment 53•17 years ago
|
||
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.
Description
•