Closed Bug 239701 Opened 20 years ago Closed 19 years ago

Some gif and png images appear corrupted, with black and shifted lines

Categories

(Core Graveyard :: Image: Painting, defect)

Product:
Core Graveyard
Component:
Image: Painting
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mike, Assigned: jdunn)

References

Details

(Keywords: regression)

Attachments

(5 files, 1 obsolete file)

Screen shot of distorted image
223.40 KB, application/pdf
Details
Icon uncorrectly displayed by camino 0.8b
8.46 KB, image/png
Details
Icon correctly displayed by mozilla 1.6
9.61 KB, image/png
Details
minimal tescase
151 bytes, image/gif
Details
Screen shot of Firefox 0.10.1 Mac OSX
55.23 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040316
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040316

Many images are distorted when rendered in browser. For instance, the layers on
http://us.i1.yimg.com/us.yimg.com/i/tv/tv2.gif appear to not be synced properly.
I have tried setting up a new profile and clearing the cache. This same image
works fine in NS 7.1 on the same machine and using Mozilla 1.6 in Windows XP
(using Virtual PC). The display of the image is distorted regardless whether it
is displayed in a page or by itself.

Reproducible: Always
Steps to Reproduce:
seems to work fine here using FF 20040402 on Win2k, can you post a screenshot ?
I believe this may be a MacOS-only issue.
I don't know whether this is related or not, but the toolbar buttons are not
displaying correctly in the mouse-over and inactive states. This is visible in
the attachment by looking at the foward and back buttons.
Seems to work fine with Mozilla 2004040505 on Mac OS 10.2.8
I can reproduce this... it's been annoying me for a few weeks now.

This is something in the core libraries...  Thunderbird and Firefox both have
this problem.  In Thunderbird, the signed and encrypted icons in the message
header (either from the built-in SMIME stuff or from Enigmail) have this
problem.  In Firefox, various images have this problem on various sites.  On the
ones I've checked so far, the problem images always seem to be PNG format
(though the attached screenshot shows it happening to a GIF).  Not all PNG
images display incorrectly.  The attached screenshot shows almost exactly what
I'm seeing - it looks like the images are interleaved, and the alternating rows
are out of sync with each other.

I can reproduce this on 3 different Macs (all three are using Mac OS X 10.3.3)
with varying versions of Firefox and Thunderbird (all nightlies, pulled within
the last few weeks)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8a?
Flags: blocking1.7?
Flags: blocking1.8a? → blocking1.8a-
Can someone track down when this regressed? There are archived nightly builds
availbable at http://archive.mozilla.org/pub/  Figuring out when it regressed
would go a long ways to getting it fixed. I don't see this in the tv2.gif linked
in the initial comment. Are there other examples you all could attach?
It works in the 2004-03-01 trunk build but not in the 2004-03-02. Based upon the
changed files in CVS, it looked like the problem was due to the fix to bug
#113406. I can also confirm that backing the changes between:
revs 1.5  and 1.6  for mozilla/gfx/src/mac/nsIImageMac.h,
revs 1.66 and 1.67 for mozilla/gfx/src/mac/nsImageMac.cpp and
revs 1.34 and 1.35 for mozilla/gfx/src/mac/nsImageMac.h
seems to fix the problem with a CVS build. However, as expected, doing so once
again causes bug #113406 to manifest. I'll take a look at the code to see if I
can see what is wrong.
Simon, not sure if you're aware of this one, this bug appears to be a regression
from bug 113406 as per commment 7.
Keywords: regression
*** Bug 244171 has been marked as a duplicate of this bug. ***
Can someone post a screenshot that's in a format that the browser can render?
that looks like some rowbyte weirdness.
Can those of you experiencing this comment on your connection speed and whether
or not a shift reload changes things? Is it always reproducible on the same
image? Can you link to some more examples?
While I'm not seeing this, I suspect that it's probably worse than the bug we
tried to fix. I'd really hate to return to failure on really large images.
Simon, do you think you'll have any time to look into this?  I think we have to
do something for 1.7 so I'm plussing this.
Flags: blocking1.7? → blocking1.7+
I need a sample image that shows this, and also info about whether it occurs for
different screen depths.
The most obvious images for me are the button bar images (reload, stop, etc.). I
just tried different screen depths. It seems to work fine at either Millions or
256. It only occurs when the depth is set to Thousands of Colors. Shift-Reload
obviously does not help.
Hmm, confirmed, I'm set for Thousands.  If you want good examples, go look at
Orkut. :)  Almost every non-photo image on Orkut is experiencing this problem.
Also confirmed, if I switch to 256 or Millions it goes away.
Attached patch patch (obsolete) — — Splinter Review 
Seems to be another bug in CopyDeepMask.  In this case, it's not handling a
mask of alpha depth = 1 correctly when the screen resolution is set to
thousands of colors.  Seems to work fine for alpha depth > 1.  In
nsImageMac::Draw, we only call CopyDeepMask if the alpha depth > 1 (for
performance reasons?), so I put that code in nsImageMac::CopyBitsWithMask.  Now
it works for all cases of varying alpha depth.
Oh, forgot to mention.  The bug in CopyDeepMask seems to be directly related to
passing the 'ditherCopy' flag.  If I change that to 'srcCopy', the problem also
went away.
Comment on attachment 149419 [details] [diff] [review]
patch

I'm not sure who should do the reviews on this so I've requested from sfraser
and tor. If that's wrong or the r/sr order is backwards and either of you can
help, I'd certainly appreciate it.
Attachment #149419 - Flags: superreview?(tor)
Attachment #149419 - Flags: review?(sfraser)
Attachment #149419 - Flags: superreview?(tor) → superreview+
Comment on attachment 149419 [details] [diff] [review]
patch

That makes perfect sense. We've seen other bugs in CopyDeepMask.
Attachment #149419 - Flags: review?(sfraser) → review+
Comment on attachment 149419 [details] [diff] [review]
patch

a=chofmann for 1.7..  can someone land today?  thanks
Attachment #149419 - Flags: approval1.7+
Whiteboard: patch ready to land
Checked in on branch and trunk.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Keywords: fixed1.7
If I switch to 256 colors, the problem does NOT go away for me, but it does go
away if I switch to millions of colors.
I attempted to verify the fix, but there's no Mac builds on the 0.9 branch and
the trunk is busted beyond usable at the moment.  I'll attempt to build my own
0.9 tonight and see what happens.
As far as I am concerned, I downloaded yesterday the camino nightly build (build
2004052808 (v0.8+)) and the problem is gone, pictures displaying correctly in
256, thousands and millions of colors.
Thanks for the fix.
*** Bug 245102 has been marked as a duplicate of this bug. ***
verified by comment #28
Status: RESOLVED → VERIFIED
checked in on aviary branch by Javier
Whiteboard: patch ready to land → fixed-aviary1.0
This patch needed to be backed out, since it led to crashes.  Seems to be an OS
bug that is causing the crashes.  While the final fix may be switching to using
Quartz rather than QuickDraw (bug 245407), we'll leave this bug open in case
anyone can think of a workaround patch.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
*** Bug 248756 has been marked as a duplicate of this bug. ***
*** Bug 249162 has been marked as a duplicate of this bug. ***
Updating summary to be more clear, and to be more findable by words used in
dupes (was "Some images are distorted in browser").
Summary: Some images are distorted in browser → Some gif and png images appear corrupted, with black and shifted lines
*** Bug 249213 has been marked as a duplicate of this bug. ***
The Image on www.sonnenblen.de with the Name
http://www.sonnenblen.de/images/newanimation1.gif

isnt correctly displayed with
Mozilla 1.8a3
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040817

BUT would be correctly rendered with
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040603

The same problem is occured with the actual releases of FireFox :-((
Attached image minimal tescase — 
This is from bug 261251 (which should be marked as a duplicate of this bug).

A 96x96 pixels (2-bit) black square GIF.
When viewed with screen set to "thousands of colors" or "256 colors", the right
one-third of the square has interlaced black and white lines.

I'm seeing this on:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913
Firefox/0.10
Flags: blocking-aviary1.0mac?
Bug 260689 is also a duplicate of this bug.
*** Bug 261251 has been marked as a duplicate of this bug. ***
*** Bug 260689 has been marked as a duplicate of this bug. ***
This bug info seems to describe the problem I have noticed with some
transparent GIF images in Mac OSX.  The problem occurs in the latest
released FireFox (PR 0.1.01)and Mozilla build 2004101105 on Mac OSX
10.3.5 on a 500MHz, 256 MB G3 iBook and 500 MHz 512 MB PowerMac G4.

The corruption or distortion seems to depend on the rendered width of
the image.  I created a test case with examples at

    http://www.studiodust.com/ff_imagetest/imagetest.html

The test includes two similar images with different widths and
each is rendered twice.  Regardelss of which images is displayed,
if it's rendered width is 352 pixels the result is distorted.

I do not currently have a screenshot that shows the problem.
If it would be helpful, I will add one to the test case page
later today.
This is a screen of transparent GIF corruption from
URL http://www.studiodust.com/ff_imagetest/imagetest.html

About Info: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3)
Gecko/20041001 Firefox/0.10.1
Problem happens for Display Color set to "thousands of colors" but not when set
for "millions of colors"
OSX 10.3.5, on my Powerbook G3 "Pismo" with ATI Rage M3P8 display hardware.

Good example: boingboing.net, where with "thousands" the jackhammer animation at
top of page appears as twins side by side, each made up of a bunch of horizontal
black lines separated by white space, moving as one, up and down.
With color set to "millions" it appears correctly.
*** Bug 265570 has been marked as a duplicate of this bug. ***
Removed "fixed-aviary1.0" status since this was backed out (see comment 32).
Whiteboard: fixed-aviary1.0
Interesting. I never saw this problem until I toggled the option for
font-antialiasing in the General System Preferences options. Now, suddently,
it's everywhere.
Blocks: 269570
Flags: blocking-aviary1.0mac?
*** Bug 273317 has been marked as a duplicate of this bug. ***
*** Bug 269570 has been marked as a duplicate of this bug. ***
I can confirm comment #44; when changing my display settings from "thousands of
colors" to "millions of colors" the bug doesn't manifest in either firefox or
thunderbird.  Switching back to thousands causes the bug to return.

Powerbook G4 12" 1.33 GHz; GeForce FX Go5200; Mac OS X 10.3.6 (7R28); Darwin 7.6.0
*** Bug 274608 has been marked as a duplicate of this bug. ***
Confirming comment #44: Bug still exists for me. I can only confirm that it
exists for animated GIFs at thousands of colors. I've got an iBook G3/600.

Using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0 on OS X 10.3.7.
*** Bug 276410 has been marked as a duplicate of this bug. ***
*** Bug 276798 has been marked as a duplicate of this bug. ***
*** Bug 277019 has been marked as a duplicate of this bug. ***
Depends on: 245407
*** Bug 279175 has been marked as a duplicate of this bug. ***
should be fixed now...
Looks good to me.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → FIXED
assuming the "orginal patch" was backed out from 1.7 as well...
Keywords: fixed1.7
Attachment #149419 - Attachment is obsolete: true
Attachment #149419 - Flags: approval1.7+
As far as I can tell, the only patch here was backed out and there's no mention
of what other patch / bug finally solved this problem.

-> WORKSFORME  (But, please correct that if there IS a specifically known
bug/patch that finally solved this - mention it in a comment.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME
This was fixed by the patch for bug #245407.
Works for me now.  YEA!!!
*** Bug 285109 has been marked as a duplicate of this bug. ***
correcting resolution based on comment 61
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
*** Bug 289349 has been marked as a duplicate of this bug. ***
*** Bug 290601 has been marked as a duplicate of this bug. ***
*** Bug 294849 has been marked as a duplicate of this bug. ***
*** Bug 296835 has been marked as a duplicate of this bug. ***
*** Bug 287373 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: