Closed Bug 408073 Opened 14 years ago Closed 14 years ago

Some frames of this animated gif image looks slightly distorted

Categories

(Core :: ImageLib, defect, P2)

x86
Windows XP
defect

Tracking

()

VERIFIED FIXED
mozilla1.9beta3

People

(Reporter: martijn.martijn, Assigned: alfredkayser)

References

()

Details

(Keywords: regression)

Attachments

(2 files)

See the image at the url.
With current trunk build, I see a slight distortion at the left of the image somewhere in the middle during the animation.
Please compare by viewing the image with a different program.

This regressed between 2007-11-07 and 2007-11-08, so when bug 143046 was fixed.
Flags: blocking1.9?
Alfred any chance you can take a look?
Assignee: nobody → alfredkayser
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
I am looking at it right now. It seems that when looping around, the second frame builds it composition not from the first frame, but from the last composite frame...
A very short patch to solve the following:
Before my 8bit patch the compositing frame was not used for all animation frames, but with my patch is does. The logic now assumes that the compositing frame is the 'current' frame, and applies the animation to that frame. 
However, the first frame does not goes through this compositing frame, so the second frame is constructed using the last compositing frame of the animation, then draw the previous frame on top (if needed), and then does 'disposal', and then draw the current frame on it.

This all works fine in normal situations. However if the first frame is not 'full' the compositing frame is not cleared correctly.

With this patch we ensure that the compositing frame will be completely cleared before the second frame is composed (by drawing prev.frame, do disposal, and then paint next.frame). 

This fixes the attached animation and keeps other animations in order.

The only risk is that the compositing frame is cleared too often
Attachment #292940 - Flags: review?(pavlov)
Confirming that the attached GIF looks correct with the v1 patch applied to the trunk on XPSP2.
Attachment #292940 - Flags: review?(pavlov) → review+
Attachment #292940 - Flags: superreview?(tor)
Flags: in-testsuite?
Attachment #292940 - Flags: superreview?(tor) → superreview+
Keywords: checkin-needed
Checking in modules/libpr0n/src/imgContainer.cpp;
/cvsroot/mozilla/modules/libpr0n/src/imgContainer.cpp,v  <--  imgContainer.cpp
new revision: 1.62; previous revision: 1.61
done
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M11
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050810 Minefield/3.0pre

Verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.