108 bytes, image/gif
1.57 KB, image/png
941 bytes, patch
Stuart Parmenter: review+
|Details | Diff | Splinter Review|
703 bytes, image/gif
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** 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...
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
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
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.
Comment on attachment 68084 [details] [diff] [review] patch file for fixing the incorrect display of the first frame r=pavlov
Attachment #68084 - Flags: review+
Comment on attachment 68084 [details] [diff] [review] patch file for fixing the incorrect display of the first frame sr=tor
fix checked in
Status: NEW → RESOLVED
Last Resolved: 16 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*
Created attachment 69876 [details] lobotomized smiley Seen on at least Win95 (2002021503) Win98, and Linux as reported on bug 125904.
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
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.