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

RESOLVED FIXED

Status

()

Core
ImageLib
RESOLVED FIXED
17 years ago
4 years ago

People

(Reporter: James Paige, Assigned: Nivedita (gone))

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
confirmed
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp

Comment 2

17 years ago
*** Bug 85735 has been marked as a duplicate of this bug. ***

Comment 3

17 years ago
Created attachment 39111 [details]
Testcase: GIF89a with transparent border (one frame, static)

Comment 4

17 years ago
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...

Comment 5

17 years ago
Created attachment 39112 [details]
PNG showing incorrect display of first frame

Comment 7

17 years ago
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

Comment 8

17 years ago
*** Bug 93881 has been marked as a duplicate of this bug. ***

Comment 9

16 years ago
Worksforme. (Build ID: 2002 01 23 04/Win98).

Could someone check if that bug still exist?
(Reporter)

Comment 10

16 years ago
Yes, I can confirm that this is still happening in Build 2002012321 on Linux an
in build 2002012403 on Windows 95

Comment 11

16 years ago
over to nivedita
Assignee: pavlov → nivedita

Updated

16 years ago
Blocks: 119597
(Assignee)

Comment 12

16 years ago
Created attachment 68084 [details] [diff] [review]
patch file for fixing the incorrect display of the first frame

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.

Updated

16 years ago
Keywords: mozilla0.9.9

Comment 13

16 years ago
Comment on attachment 68084 [details] [diff] [review]
patch file for fixing the incorrect display of the first frame

r=pavlov
Attachment #68084 - Flags: review+

Updated

16 years ago
Attachment #68084 - Flags: superreview+

Comment 14

16 years ago
Comment on attachment 68084 [details] [diff] [review]
patch file for fixing the incorrect display of the first frame

sr=tor

Updated

16 years ago
Blocks: 111166

Comment 15

16 years ago
fix checked in
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 16

16 years ago
*** Bug 114080 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 17

16 years ago
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...
(Reporter)

Comment 18

16 years ago
Works with build 2002021203 on Win95. Nice work! *dance of joy*

Comment 19

16 years ago
Created attachment 69876 [details]
lobotomized smiley

Seen on at least Win95 (2002021503) Win98, and Linux as reported on bug 125904.

Comment 20

16 years ago
sri spam
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 21

16 years ago
*** Bug 125904 has been marked as a duplicate of this bug. ***

Comment 22

16 years ago
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.

Comment 23

16 years ago
I stand corrected.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.