Closed Bug 86508 Opened 23 years ago Closed 22 years ago

first frame of transparent animating gif displayed at the wrong position/size

Categories

(Core :: Graphics: ImageLib, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: MozillaUser, Assigned: nivedita)

References

()

Details

Attachments

(4 files)

Using Build 2001061804 on Windows 95 (this bug has been present since day 1 of
imagelib2, but I wanted to wait for bug 77914 to be fixed before I reported it)

View the animating transparent gif at http://HamsterRepublic.com/img/bobhitjames.gif

Notice that the first frame is displayed wrong. The image is misaligned with its
transparency. Once the animation gets past the first frame then it continues
looping correctly.

Now visit http://HamsterRepublic.com/html/ohrrpgce.html
The exact same image is displayed near the top, this time in an <IMG> tag that
stretches it to twice its normal size. Note that the first frame is displayed
stretched out, but after that it loops correctly.

It appears to me that imagelib is making the _incorrect_ assumption that the
first frame of the animation must be the same size as the full size of the
animation.  If the first frame is smaller than the total size of the animation,
then imagelib is stretching it. The correct behavior would be to draw the first
frame of the animation at the correct size and position, leaving any other
pixels in the image as transparent. This is exactly how it already handles later
 non-first frames of the animation that have sizes different than the size of
the whole gif, and how it handles the first frame when it gets back to drawing
it again as it loops.
confirmed
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp
*** Bug 85735 has been marked as a duplicate of this bug. ***
I've attached a simple testcase - an 80 by 80 single-frame GIF89a with a nice
thick transparent border (as per Bug 85735 which was duped to this bug). It
looks like imglib2 Mozillas render it using the Frame Descriptor (gives bounding
rectangle of opaque area) instead of the Logical Screen Descriptor (actual size
of image).

With http://HamsterRepublic.com/img/bobhitjames.gif I am seeing a different
problem in the first frame - the masked area is correct (as seen by the
"outline" of the two characters), but in the opaque area the frame is rendered
scaled to the full height of the image (so the opaque area looks corrupted as
you can only see bits of the scaled cartoons). I shall attach it next...

Yeah, it displays wrong in Linux too...  It displays differently than it does in
Windows though...  Dunno what to do about that.  Will just mark All/All now.
OS: Windows 95 → All
Hardware: PC → All
*** Bug 93881 has been marked as a duplicate of this bug. ***
Worksforme. (Build ID: 2002 01 23 04/Win98).

Could someone check if that bug still exist?
Yes, I can confirm that this is still happening in Build 2002012321 on Linux an
in build 2002012403 on Windows 95
over to nivedita
Assignee: pavlov → nivedita
Blocks: 119597
For the first frame we were using the entire animated gif dimensions rather the
current frame. Hence construcing the first frame, with the current frame
dimensions rather than entire frame dimensions. The image was misaglined with
the transparency because the masking was done before drawing the image.
Keywords: mozilla0.9.9
Comment on attachment 68084 [details] [diff] [review]
patch file for fixing the incorrect display of the first frame

r=pavlov
Attachment #68084 - Flags: review+
Attachment #68084 - Flags: superreview+
Comment on attachment 68084 [details] [diff] [review]
patch file for fixing the incorrect display of the first frame

sr=tor
Blocks: 111166
fix checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 114080 has been marked as a duplicate of this bug. ***
groovy! I just tested http://HamsterRepublic.com/img/bobhitjames.gif with build
2002021206 on Linux, and it is working properly.

I cant test Win 95 yet, because I am still finding a Feb 11th win32 build on the
ftp server right now...
Works with build 2002021203 on Win95. Nice work! *dance of joy*
Attached image lobotomized smiley
Seen on at least Win95 (2002021503) Win98, and Linux as reported on bug 125904.
sri spam
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 125904 has been marked as a duplicate of this bug. ***
As far as i can tell, bug 125904 is a dup of bug 22607 and not a dup of this bug.
The testcases there are OK now.
According to how the GIMP lays the frames out, bug 125904 is not about the first
frame, but about the LAST frame, going transparent to page background instead of
to background frame of the gif.
I stand corrected.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: