Closed
Bug 86508
Opened 24 years ago
Closed 23 years ago
first frame of transparent animating gif displayed at the wrong position/size
Categories
(Core :: Graphics: ImageLib, defect)
Core
Graphics: ImageLib
Tracking
()
RESOLVED
FIXED
People
(Reporter: MozillaUser, Assigned: nivedita)
References
()
Details
Attachments
(4 files)
(deleted),
image/gif
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
patch
|
pavlov
:
review+
tor
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
image/gif
|
Details |
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•24 years ago
|
||
confirmed
Comment 3•24 years ago
|
||
Comment 4•24 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•24 years ago
|
||
OS is probably all since i see this on Linux.
http://www.lokigames.com/home/_img/topics/heavy-gear2.gif
http://www.lokigames.com/home/_img/topics/heretic2.gif
Comment 7•24 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 9•23 years ago
|
||
Worksforme. (Build ID: 2002 01 23 04/Win98).
Could someone check if that bug still exist?
Reporter | ||
Comment 10•23 years ago
|
||
Yes, I can confirm that this is still happening in Build 2002012321 on Linux an
in build 2002012403 on Windows 95
Assignee | ||
Comment 12•23 years ago
|
||
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 13•23 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+
Attachment #68084 -
Flags: superreview+
Comment 14•23 years ago
|
||
Comment on attachment 68084 [details] [diff] [review]
patch file for fixing the incorrect display of the first frame
sr=tor
Comment 15•23 years ago
|
||
fix checked in
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 16•23 years ago
|
||
*** Bug 114080 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 17•23 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•23 years ago
|
||
Works with build 2002021203 on Win95. Nice work! *dance of joy*
Comment 19•23 years ago
|
||
Seen on at least Win95 (2002021503) Win98, and Linux as reported on bug 125904.
Comment 21•23 years ago
|
||
*** Bug 125904 has been marked as a duplicate of this bug. ***
Comment 22•23 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•23 years ago
|
||
I stand corrected.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•