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.

Alfred any chance you can take a look?

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

Confirming that the attached GIF looks correct with the v1 patch applied to the trunk on XPSP2.

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

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050810 Minefield/3.0pre Verified.