Closed Bug 73195 Opened 23 years ago Closed 23 years ago

interlaced gifs are corrupted when first drawn

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: ajbu, Assigned: tor)

References

(
URL
)

Details

(Whiteboard: [imglib] want for mozilla 0.9.1; has patch, r=, sr=; needs a=)

Attachments

(7 files)

Screenshot of Mozilla.org loading the first time
38.14 KB, image/png
Details
fix
2.11 KB, patch
Details | Diff | Splinter Review
more gif update logic for interlaced gifs
4.75 KB, patch
Details | Diff | Splinter Review
same + dup count fix attempt (my connection is too fast to test)
6.19 KB, patch
Details | Diff | Splinter Review
same + setting progressive display in GIF2.cpp
6.76 KB, patch
Details | Diff | Splinter Review
same + reset progressive display to false for overlays
7.08 KB, patch
Details | Diff | Splinter Review
same + combined nsGIFDecoder2::FlushImageData()
6.50 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
BuildID:    2001032304

Loading Mozilla.org the first time doesn't correctly render the mozilla-
banner.gif. After scrolling the image offscreen of moving another window over 
it, it is shown correctly. 

Reproducible: Always
Steps to Reproduce:
1. delete profile or cache directories 
2. Start Mozilla
3. go to http://www.mozilla.org, and watch header-gif
4. move another window over the gif, or scroll gif out of view, and show it 
again, it now shows correctly.

Actual Results:  Gif not rendered properly

Expected Results:  Gif completely rendered.

Seen this on two computers (2001032304, and home-build with newcache en 
libpr0n). I completely deleted my profile, reloading (F5/Ctrl-F5) or restart 
mozilla shows the gif correctly.

    
    

    
  
Confirmed on WinNT 2001032304.


Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
libpr0n bug (it's on in that windows build already)
Assignee: pnunn → pavlov

    
    

    
  
Correct Boris, I ment to suggest we add this bug to the libpr0n tracking 
bug...I will do that if it has not been done already.

    
    

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

    
    

    
  
*** Bug 73408 has been marked as a duplicate of this bug. ***
Blocks: 66967

    
    

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

    
    

    
  
A method to reproduce this (Build ID: 2001032604):
1. take this picture from the Web: http://office.altkom.com.pl/mozilla/logo.png
or from the attachment 28808 [details] )
2. Place it locally on your HDD (when opening it remotely doesn't work every time)
3. Try to open it with File->Open

Its display's corrupted. However, if you switch to another window and switch back
to mozilla, the image will display correctly without even having to to be reloaded!
Immediate following reloads of the image don't show the corruption. However, if
you wait a considerable amount of time (a couple of minutes maybe) then, after
reloading, it will display corrupted again.
This problem occurs not only with PNGs, I've also seen it happen with JPGs and
GIFs (the one on Google's frontpage for example), but couldn't reproduce it on
remote pics - they don't corrupt the second time, sometimes even never again...
I also experienced crashes when displaying the corrupting pic (Talkback IDs:
TB28277471E - when opening locallly
TB28276985E - when opening locallly
TB28309466H - when opening from
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=28808
), but those may be unrelated, I noticed similar crashes with this build elsewhere.
I tested it with today's Linux builds, but all worked fine.

    
    

    
  
Shouldn't this bug's component be changed to "Compositor"? That problem occurs
regardless of image type and only when displaying on screen, not during loading.

    
    

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

    
    

    
  
changing summary per comment from Aleksander Adamowski.
confirmin' same behavior.
Summary: Mozilla.org gif doens't render properly the first time shown → Images are corrupted when first drawn

    
    

    
  
could also be blocking bug 73328 (Throbber is broken)

    
    

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

    
    

    
  
Confirmed on Windows 98-win32 Build ID: 2001032704

Was not present in build from March 18: 20010318??
(I update once per week on Sundays and image loading was working fine until my
most recent update this week)


    
  
Blocks: 73328

    
    

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

    
    

    
  
While there is an easy work-around for this, it is still making it REALLY
annoying to browse with mozilla. I am probably going to have to roll back to the
last version that didn't have this bug and wait for a fix to come through...

    
    

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

    
    

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

    
  
Keywords: mostfreq

    
    

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

    
    

    
  
The workaround for this bug, mentioned earlier, doesn't fix the problem in bug
74235. Scrolling the images in http://hadrian.org/public/ off screen, or
covering them with another window, does not cause Mozilla to display them when
the browser window is uncovered or scrolled to its original viewing position --
they remain completely blank. I'm seeing the corrupted display of other
graphics, with work-around, elsewhere though. Linux nightly 2001033105.


    
    

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

    
  
Keywords: mozilla0.9, 
          
            nsbeta1

    
    

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

    
  
Whiteboard: [imglib]

    
    

    
  
John Hayward-Warburton: Can you reproduce it on latest Linux builds? I don't see
anything wrong in http://hadrian.org/public/ 
I'm using Mozilla 2001040208 (Linux-i686).


    
    

    
  
This particular bug might (?) be something different. Resizing the image (within
the IMG) tag tickles this one. Please see bug 74235 and my new testcase at
http://johnwarburton.net/nopic/


    
    

    
  
On Windows 95, build 2001032804, MOST images do not display correctly.

I have found a very easy way to get them to render correctly...  just drag the
image a bit by holding down the left mouse button on the image and moving the
mouse a bit.

    
    

    
  
I'm also noticing 90% reproducible crashes when i place the file
http://office.altkom.com.pl/mozilla/logo.png
 locally on my HDD, make copies of it with different names (logo2.png,
logo3.png, logo4.png) and open one of them instantly after starting Mozilla
(through File->Open), before loading any web page.

Win32 talkback build 2001040204.

Talkback ids: 
TB28591438Y
TB28591412K


    
    

    
  
Since the images started becoming corrupted I've also noticed two other things:
http://www.dilbertzone.com/comics/dilbert/archive/
If you rightclick and view the daily comic in a new window and try and print it
will shrink the image to the point where it's illegible.  This started happening
when the images weren't displaying properly.

Second.  When I installed build 2001040304 today and went to checkout the above
site the images that I had set as blocked were still blocked but 100% visable on
the page.  When the corrupted images first appeared blocked images would show up
as a black box with white lines through it and often had flashing parts within
the blocked area.  Even unblocking and reblocking the image made no difference.
 The blocked images were still 100% visable.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        fix
        — 
          — Splinter Review
      

    


  

    
    

    
  
patch from Kevin McCluskey (kmcclusk@netscape.com) to fix this bug.  r=pavlov

    
    

    
  
sr=jst, for what it's worth.

    
    

    
  
fix checked in

    
    

    
  
Still seeing some corruption (though not as much) on 2001040409 Linux

    
    

    
  
Looks good now on Windows 95 with build 2001040404.

I notice some chuffyness on progressive rendering of PNGs, but Im pretty sure
that is material for a separate bug.

    
    

    
  
Resized images (width/height in <IMG...> tag not in agreement with actual image
size) still do not display at all on X Mach64 display (but are fine on S3
Trio3D/2X) with Linux build 2001040409, X-4.0.3.


    
    

    
  
Several animated GIFs look broken on build 2001040409 (and earlier versions of
the new Image library), Linux (both my displays). See, for example,
http://silversurfers.uk.com/includes/ad_here.gif    Each layer doesn't appear to
be offset in the correct place, and the blank layers between each 'flash' of
text don't work correctly.


    
    

    
  
John: You should probably best check if those problems are already filed, and 
otherwise post those problems as new bugs. This one is for images corrupted on 
first draw, there are animated gif and Linux problems elswhere. The problems 
you mention seem OS specific and should be filed for that platform/OS to get 
the attention they deserve.

    
    

    
  
minimal amount of coruption still present on linux 2001040414. Usually shows up
in large pictures or pictures loading from low bandwidth connections, when they
load top to bottom (not progressively). In such cases I see 1-pixel wide white
horizontal lines.

    
    

    
  
Still seeing problems on Win2k. Load this page (http://www.ultimatezip.com/) and
check out the screenshots on the right side. They seem to partly load, but then
they fully appear if you mouse over them (?). Weirder still, there's no
JavaScript "mouseover" associated with those images. 

    
    

    
  
I can reproduce Alex Bischoff's report exactly on Win 98 (2001040504).

    
    

    
  
I can also reproduce Alex Bischoff's report on WinNT (2001040504)

Also probably a better example page is http://www.themes.org because it has 
dozens of images all over the place.  Just go there and refresh the page a 
couple of times and random images will not completely draw.  This could be a 
cache issue since resizing will not force the images to draw.



    
    

    
  
Two, three additional data points.

1. http://www.ncmag.com/2001_03/toc.html

Using win32 2001041004 shows two patterns:
image of the magazine's cover is distorted (black lines) until the image is
clicked.  I was able to reproduce this over and over, yet now (with several Mozs
open) the pattern has changed: image is initially distorted as above but then
clears itself.

Using linux 20010401 shows one pattern:
no image at all.

2. http://www.ibm.com
Big Blue's logo image (upper left) blinks on both builds mentioned above, with
the additional problem that on linux the image is only half drawn from top to
middle.


    
    

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

    
    

    
  
marking this fixed.  there are plenty of other open bugs about animated images 
and linux scaled drawing bugs.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
It seems like this has reappeared.  Build 2001050104, Win98.  When I visit
http://www.comics.com/comics/luann/, the Luann comic will sometimes draw with a
few black lines near the top.  Clicking on the image makes the lines go away.

    
    

    
  
Confirming on win32-talkback build 2001050104
A few black lines at the top.
As previously with this bug scrolling image offscreen and back results in image
being displayed properly.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
this isn't that bug.  there are numerous new bugs about nothing drawing right
the first time around due to a bunch of new bugs in the view manager I expect. 
re-resolving fixed.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
This is still happening to me on build 20010505 Win98. The browser reliably
messes up this page:

http://ien.virtualave.net/ob/

Stop marking this fixed! If there is another bug for this error, mark it as a
duplicate of this one. We need this bug to have the mostfreq status.

    
    

    
  
I also can confirm this. The pic is splitted in 3 rows and the upper is some 
times drawn with horizontal lines. After clicking on the image all displays 
fine.

    
    

    
  
If there's a problem with libpr0n, maybe we might to better seeing if when it's
removed if this will go away.   *sigh*   No offense to anyone...

Everytime something like this happens somebody does something else to slow down
painting, disabling the eager paint is causing some nasty slow downs. 

(I fear we are heading the wrong way on this)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Ever since libpr0n was added, we've had nothing but problems. IMNSHO, it needs
to go. Away. Far, far away.

    
    

    
  
No problem, we'll reopen all the bugs it fixed, and you can fix them in the old
code. Or try to.

If you have something constructive to say, do it.

    
    

    
  
Look, this bug is fixed.  Go look at bug 74129 if you want to cry about things
not drawing.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Depends on: 74129
Resolution: --- → FIXED

    
    

    
  
Saari, Pavlov: the problems I've been seeing in the latest builds don't seem to
be the same as what's described in bug 74129.  I'm seeing problems with images
with black stripes through them, on the first time they're loaded.  As far as I
know, there's no "damage" to the view.  Is that really bug 74129, or something else?

    
    

    
  
ok, fine, i'll reopen this and look into it in greater detail.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

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

    
    

    
  
This has nothing to do with bug 74129 and everything to do with bug 73195.
Instead of being rude to testers and closing bugs, why don't you Netscape people
work on fixing the problem? I guess AOL has had an effect on you after all.

    
    

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

    
    

    
  
I can be wrong, but I belive all corrupted pics are with <a href>...

    
    

    
  
Eugene, I don't think you're right, see bug 79379, which is a duplicate but it
doesn't have <a href> at all.


    
    

    
  
Hoping to maybe clear up on which problems are still there and which aren't... I
went through the various examples in these comments on win98,
2001-05-08-17-trunk. This is what I see, YMMV:

http://www.mozilla.org banner : ok, no attachment 28607 [details] sorta problems.
Attachment 28808 [details] : ok.
Crashes on rendering images as described on March 26th by Aleksander Adamowski :
haven't seen this since 20010402.
http://hadrian.org/public/ : ok.
http://johnwarburton.net/nopic/ : ok.
http://www.dilbertzone.com/comics/dilbert/archive/ : comic always corrupts on
shift-reload.
http://silversurfers.uk.com/includes/ad_here.gif : ok.
screenshots at http://www.ultimatezip.com/ and http://www.themes.org/ : ok.
http://www.ncmag.com/2001_03/toc.html : corrupts.
http://www.ibm.com/i/v10/m/en/lanim.gif : ns47 and ie55 show the animation once,
mozillla repeats it.
http://www.comics.com/comics/luann/ : corrupts occasionally.
http://ien.virtualave.net/ob/ : can't get it to stay corrupt when loading whole
page, but shift-reloading only the image http://ien.virtualave.net/ob/cc.gif
does leave the black lines in top 1/3.

attachment 32248 [details] seems reliable enough for testing. Shift-reload to get
progressive display; All scans don't seem to hit the top lines. The remaining
black lines are slightly differently placed each time. Why is the image area
mostly filled with black during the progressive rendering in the first place?



    
    

    
  
right... "Interlaced GIFs often finish rendering with stripes" is covered by bug
73972, "Mozilla repeating animation of images when it shouldn't" is bug 75828,
black background in interlaced rendering is covered by bug 76703. That's all the
problems I see, so I guess this bug is useless and too confused to keep.

    
    

    
  
For me, url http://johnwarburton.net/nopic/ is not fixed. The resized image
refuses to display on the ATIMach64 card; the Trio S3/2X card does work. Most
odd, but this is still the original problem. I believe another bug has been
opened for this?

    
    

    
  
Ermmmm... Tuukka, I don't agree. It happens for non-interlaced GIF's too, 
especially when they are large and also are coming from a slow server. Seems 
like the renderer keeps rendering without waiting for the necessary data to 
arrive, or something like that. I don't think it has to do with cache, since 
when I shift-reload from the proxie's (!) cache the image works.


    
    

    
  
I saw it today at
http://forex.mdmbank.com/finance/forex/info.htm?cur1=EUR&cur2=USD - every minute
updated image.

Reload it (with shift, I had already filled a bug for this) and you will
probably see it some time.

    
    

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

    
    

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

    
    

    
  
This may or may not be related. Loading the weathermap from
http://www.weather.com/maps/maptype/forecastsusnational/useveningforecast_large.html
is always corrupted when drawn the first time - when the image is being drawn
incrementally.  The last 10 or so pixel rows are drawn correctly.  When the
image is being drawn from cache (either Mozilla's own, or a local (fast) squid
cache) the image is rendered correctly.
(System is linux RH7.0, Mozilla build 2001050521 = 0.9, on a 300Mhz K6, display
is ATI rageII graphics)

    
    

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

    
  
Whiteboard: [imglib] → [imglib] DUPME

    
    

    
  
Pav sez: this is a known dup of one of his 0.9.1 bugs... marking target as such.
Target Milestone: --- → mozilla0.9.1

    
    

    
  
ok.  i've checked in a fix for this.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
For the brief period of time I was able to use build 2001051820 Win98, this bug
was not fixed. The "Chrono Cross" graphic was still glitching upon shift+reload
reliably at <http://ien.virtualave.net/ob/>.

    
    

    
  
The image of the weird dude at the top right hand corder of
http://www.digitalblasphemy.com is corrupted with 2001052109/Linux

    
    

    
  
He looks fine with 2001052108 linux !


    
    

    
  
Well, it messed up the three times I visited the page at work. However, it
renders correctly here at home with the same build (2001052109) and a newer
build (2001052115).
But, if I shift+reload several times (or sometimes the first time) the image
messes up. I suppose this may be a different bug though... I'll test it again at
work tomorrow.

    
    

    
  
I think ticmanis@coli.uni-sb.de was right.  The only time I see this problem is 
when the transfer seems to be a little slow.  I haven't seen this problem when 
the transfer speed is good, or from images coming from a local drive.

    
    

    
  
For some reason every time I view http://www.digitalblasphemy.com on my computer
here at work, the image is corrupted. I don't know about the slow connection
theory since the page loaded pretty fast and I'm getting ping times of 163 from
said site.
As I said before, the image loaded fine at home.

Work PC:
- PIII 500
- 192MB RAM
- ATI Rage Pro
- 19in Sun monitor
- Mandrake 8.0/Enlightenment 0.16.5

Home PC:
- PII 233
- 224MB RAM
- STB Velocity 128
- 17in Dell monitor
- Progeny 1.0/Enlightenment 0.16.5

    
    

    
  
I've seen it today with 20010522 Win32 installer build on a fast connection.

    
    

    
  
Just saw this at the target store locator on 2001052209/Linux (go to
http://www.target.com and click on Store Locator under the "STORE" heading near
the bottom of the page). The map that shows up after searching for a store is
corrupted.

BTW, the computers I listed above are on a T1 and a cable modem, respectively.

    
    

    
  
I would seem that the consensus here is: please reopen this bug.


    
    

    
  
seeing on linux 2001052208, re-opening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Some comments:

0) People - including me - see this on cablemodems and T1 connections [a
statement of fact]

1) Even if it happened only with slow conncections, it would still be a bug

2) This is a kind of bug anyone (even a moron^H^H^H^H^H non-technical person)
will see. We may concern ourself more with things like full XML or CSS
compatibility, issues we have with copy&paste, drag&drop etc. etc. that most
people do not even fancy to use. But opening a Web page and seeing a corrupted
image of whatever is the important thing to the average Joe is a big turn-off.

Ergo: this should have a high priority as a public relation issue (or Mozilla
evangelism, in a more general meaning that the one used on bug pages)

    
    

    
  
by "corrupted" you are seeing the image stretching when it shouldn't?  Or are 
you seeing the bug where progressive gifs don't always draw correctly the first 
time?  I'm seeing this scaling bug... but thing that perhaps a new bug should be 
filed on it and re-mark this one fixed.  (there are a few bugs on the 
progressive gif thing already)

    
    

    
  
both. For example:

http://hamsterrepublic.com/img/bobhitjames.gif is stretched when it shoudlnt be.

http://www.westcoastaerospace.com/gif/wcalogo.gif renders with several black
horizontal lines on the top edge the first time you load it

However, I am pretty sure that this bug was ORIGINALY filed for horizontal white
and black lines and noise in images the first time they are loaded (much worse
than what appears now)

    
    

    
  
Those last two URL's both look fine to me with Linux build 2001052108.


    
    

    
  
i can reproduce both problems on windows...

the original bug was due to clipping problems... the "current" bug is due to 
some lack-o-drawing

    
    

    
  
This doesn't have to do with clipping. The effect is always the same: some
horizontal zones in images are blank, and what should be there appears in a
vertically severely squashed form (above or ??) below the blank areas. Only when
the missing parts are small you won't notice the second affect since it's just
squashed out of existence more or less. A reliable test case should be a really
large .gif on a purposefully slowed down server.
The images don't have to be progressive either, just e.g. the huge gif's at
http://www.irr.org/mit/BOM/1830bom-p408.html and the rest on that site. The're
conventional black-and-white only, scanline-by-scanline images and get messed up
really badly.


    
    

    
  
Confirmed existing in 2001052213 / Linux, with the URL I gave above.


    
    

    
  
on linux i always see this at http://www.linuxcentral.com

    
    

    
  
Linuxcentral looks like a good testcase. I saw image corruption here, but not on
other pages.


    
    

    
  
Linards comments from 2001-05-22 15:30 sum up the problem pretty good (I can
confirm on Linux RH 6.2, cvs build 05-25). I can provide attachments that
demonstrate the scaling (in contrast to clipping), if anyone so desires. I also
found that in case you have such a corrupted drawn image and loads a different
page per bookmark, the image is also redrawn correctly until the new page starts
displaying. I found this odd: having a repaint of the page if you want to load a
different page anyway. (BTW, the blank area is alway dark blue in my case, never
black)

    
    

    
  
I am seeing the black lines when I load the images of Boondocks at
http://www2.uclick.com/client/wpc/bo/

in Mac 2001052408 build. All/All.
OS: Windows 2000 → All
Hardware: PC → All

    
    

    
  
Here's an interesting tidbit...

If I drag another window over the affected image, it will fix the black line
problem in the area where it was covered by the window. This is particularly
visible if you drag Winamp over the glitched graphic. If we could activate a
window refresh of some sort (refresh as in redraw, not refresh as in reload, the
way IE interprets it...), right after the page finished loading, that could fix
the problem (although the black lines would still be visible while the page is
loading, so it wouldn't be a COMPLETE fix).

    
    

    
  
skewer: 
if every image would be redrawn, Mozilla would get much slower. 
The only acceptable solution is to draw the image correctly the first time.

    
    

    
  
Seems like it could be dependant on ceonnection speed. I am using a cable modem
(512K) which might explain why I didn't see some corruptions that others reported.


    
    

    
  
I don't think so. I see problems with my 768k SDSL at home, and also at work
with multiple 45mbit links. Doesn't seem to depend on the speed of the remote
site, either.

    
    

    
  
Speed definitely doesn't matter; I'm seeing this on my cablemodem.  Sometimes
it's just thick black bars through the image that are fixed on a click/redraw;
other times, it's a series of 1-pixel-wide black bars, only with very small images.

I'm using an ATI All-In-Wonder; I understand there's an imglib error only
related to ATI Rage cards?

Could someone update the keyword to mozilla0.9.1?  0.9 was a while ago:)

    
    

    
  
Mark B.: It's not ATI only, I get it on my NVidia Riva 128. Oh and the Target
milestone is correctly set, only the keyword is wrong.

    
    

    
  
Right, but the keyword field should be consistent with target. Changing the
keywords...
Keywords: mozilla0.9, 
          
            nsbeta1 → mozilla0.9.1

    
    

    
  
I'm seeing this on a Voodoo3 3000 AGP @ 800x600x16/32bppx100hz. Doesn't seem to
depend on hardware.

Build: 2001052720 Win98

    
  
Target Milestone: mozilla0.9.1 → mozilla0.9.2

    
    

    
  
If it can't be done for 0.9.1, we might correct the keywords as well. Please?

    
    

    
  
Changing the keywords again :-(
Keywords: mozilla0.9.1 → mozilla0.9.2

    
    

    
  
The problem lies in the minimal update logic in the gif decoder.  It only
tracks the last flushed row and doesn't notice that the current row has
wrapped around, so the appropriate rectangles aren't updated.

The attached patch adds logic to handle the interlace wrapping.  There is
still the problem that the row repeat count is ignored in HaveDecodedRow,
but that's another bug (#?).

Summary: Images are corrupted when first drawn → interlaced gifs are corrupted when first drawn
Whiteboard: [imglib] DUPME → [imglib] want for mozilla 0.9.1

    
    

    
  


  

    
    

    
  
Taking bug, sticking on 0.9.1 radar.

Assignee: pavlov → tor
Status: REOPENED → NEW
Target Milestone: mozilla0.9.2 → mozilla0.9.1

    
  
Whiteboard: [imglib] want for mozilla 0.9.1 → [imglib] want for mozilla 0.9.1 has patch, needs r= and a=

    
  
Status: NEW → ASSIGNED
Whiteboard: [imglib] want for mozilla 0.9.1 has patch, needs r= and a= → [imglib] want for mozilla 0.9.1; has patch; needs r=, sr=, and a=

    
    

    
  
r=pavlov

    
  
Whiteboard: [imglib] want for mozilla 0.9.1; has patch; needs r=, sr=, and a= → [imglib] want for mozilla 0.9.1; has patch, r=; needs sr=, a=

    
    

    
  
r=saari, thanks for jumping on this tor!

    
    

    
  
The two |switch| statements look an awful lot alike. If there is no salient
difference between the two (I looked at them only cursorily), I'd suggest making
a function (inline, if you're worried about call overhead). Other than that,
sr=waterson (I'm not at all familiar with the image decoders, so I'll trust pav
& saari looked at this carefully...)

    
    

    
  
r=pavlov on the latest patch

    
  
Whiteboard: [imglib] want for mozilla 0.9.1; has patch, r=; needs sr=, a= → [imglib] want for mozilla 0.9.1; has patch, r=, sr=; needs a=

    
    

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

    
    

    
  
a=blizzard received in mail.

Checked in.

Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
Thanks tor! Can't reproduce the problem with GIFs anymore, so it seems fixed.
However, with JPGs I still see the same problem, but as this summary only refers
to GIFs that would be different bug. Does anyone know which one? I found several
JPG-related bugs, but none that appears to have the same symptoms as this one ..

    
    

    
  
I just thought -- do progressive JPEGs and
interlaced PNGs have the wraparound problem?


    
    

    
  
Hmmm..  I hate it when someone beats me to a thought... :-)

    
    

    
  
If there is not a bug for jpegs and it cannot be part of this one then who is
going to submit one?  I have been following this for a couple of days having
just started dinking with redhat 7.1 and encountering this bug.  Frankly I did
not notice that this bug was gif only until the last comment.

An additional data point:

I found this by testing our software that runs a non interactive display that
scrolls through a list of html files local to the machine so all are read from
the harddrive.  After tuning the disk access with hdparm and recompiling the
kernel (I forgot to include dma mode support and support for the via chipset) I
do not see this anymore.  No mozilla changes.

If there is something I can test on this platform K6-2 300MHz using XFS
filesystem let me know.  I am new to mozilla but would like to help anyway I
can.

BTW image loading ingeneral is very slow compared to netscape 4.x but I suspect
that belongs in another bug :)

Bret 

    
    

    
  
I don't know if this applies, but there were a lot of patches to disable the
eager paint behavoir possibly in an attempt to cover for this bug (my
speculation: which is, most likely, flawed)...   I would be curious that if that
fast paint behavoir were reenable would the corruption return (if this fixed the
original problem...)

My $0.02 USD... :-)


    
    

    
  
Wouldn't a spill checker be nice for bugzilla ??? :)

    
    

    
  
Which build contains this fix? I'm still seeing this in 2001053104 Win98. Just
as bad as ever.

    
    

    
  
2001053104 is too early to have this fix as it was checked in at about 7:30
(both Pacific time). 

    
    

    
  
Not only does this WFM in 2001060104 Win98, but it looks like this update fixes
bug 76703! Would verify if I could.

    
    

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

    
    

    
  
Veryfying on Skewers comment and my own observations.
Status: RESOLVED → VERIFIED

    
    

    
  
Jacek, bugs which have been resolved as FIXED must be verified on all the
platforms reported against.  In this case the bug needs to be verified on win32,
linux and Mac since the Platform is set to ALL.

    
    

    
  
Right. Unlike the other GIF bugs this one is not Windows only. Mea culpa.

Reopening in order to mark fixed again.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

    
    

    
  
We need verification on the fixed staus from Linux and Mac plaftorms.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
I verify that the type of corruption covered by
this bug is fixed on Linux.

    
    

    
  
Marking verified per comments above and 
verified fixed mac build 2001060408
verified fixed w2k build 2001060409
Status: RESOLVED → VERIFIED

    
    

    
  
Sorry to say, this one is alive and kicking on 0.9.1. (Linux 2001060713) See
e.g. http://www.irr.org/mit/BOC/1833boc-p1.html. Or is that another bug? But it
looks as always, so I think it simply was not really fixed.




    
    

    
  
Hmm, I see what you mean.  This case is still bad.
URL: http://www.mozilla.org → http://www.irr.org/mit/BOC/1833boc-p1...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

    
    

    
  
I haven't seen any corruption like this on Win2K 2001060704
(win32-installer-sea-talkback.exe) (1600x1200x32)

Was that image interlaced on the last test case?  My loaded like a
non-interlaced on a slow connection (56K) and without fault.

WFM?

Is there something your looking for that I'm not seeing?  One issue might be
that the image in question was "resized" smaller than the original... I don't
know if that was a contributing factor...

    
    

    
  
I think this bug had moved past interlaced gifs for a long time before it was
last closed. Well I also saw this effect on some non-resized pics in www.cnn.com
however the larger the image and the slower the link, the worse the corruption,
it seems. It definitely does not WFM. Maybe I'll try a nightly as well.. hold
on...

    
    

    
  
Seeing it on Linux 2001060621.

I've got to agree with Thomas Swan. This looks like a different bug. While black
bars do appear, there is also a virtical compression going on. It now only
happens on large images, while this one effects even the smallest. 



    
    

    
  
Confirming on 2001060721 Linux. Someone with permission might want to just
change the Summary of this bug instead of filing a new one, as it already has a
lot of comments on the very effect I reported earlier this morning.

    
    

    
  
You're right, the given faulting image is non-interlaced -- I assumed
it was interlaced.  I don't think that this bug needs any further
morphing, so I'm closing it again for now and recommend that another
bug is filed.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
re-verifying as if today never happened.
Status: RESOLVED → VERIFIED

    
    

    
  
I've just filed bug 84629 for the "new" (actually not so new) problem.

    
    

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

    
    

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

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: