Closed Bug 897488 Opened 10 years ago Closed 10 years ago

Semi-Transparent, animated gifs don't play/loop correctly


(Core :: Graphics: ImageLib, defect)

25 Branch
Not set



Tracking Status
firefox24 --- unaffected
firefox25 --- verified


(Reporter: me, Assigned: joe)



(Keywords: regression)


(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130723 Firefox/25.0 (Nightly/Aurora)
Build ID: 20130723030205

Steps to reproduce:

Using current nightly, semi-transparent GIFs don't play correctly, at least on Windows. See this example:

At least on my Windows machine, I see two frames of the animation switching back and forth here. Opening the image in a new tab or setting the opacity to 1 seems to correct the problem.

This may be a Windows only bug as Joe Drew reports this case as working on OSX.

The problem appeared maybe 1-2 weeks ago, and I'm pretty sure it may be a regression from a patch landed in bug 717872.
Blocks: omtagif
I'm on OS X (10.8.4) and I can reproduce this behavior using Firefox Nightly 25.0a1 (2013-07-24).
Oh wow. It doesn't happen on my UX nightly, which is synced to mozilla-central only occasionally, but it *does* on my regular nightly!
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86_64 → All
Last good nightly: 2013-07-22
First bad nightly: 2013-07-23


Which implies it can't be OMT gif!
No longer blocks: omtagif
(In reply to Joe Drew (:JOEDREW! \o/) from comment #3)
> Last good nightly: 2013-07-22
> First bad nightly: 2013-07-23
> Pushlog:
> pushloghtml?fromchange=2268ff80683a&tochange=5ceea82a79c7
> Which implies it can't be OMT gif!

I can reproduce the problem in your Good build....

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130704 Firefox/25.0 ID:20130704094644
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130704 Firefox/25.0 ID:20130704114744

Suspected: Bug 717872
I trust Alice way more than I trust me.
Assignee: nobody → joe
Blocks: omtagif
It works as expected if set 
gfx.direct2d.disabled = true
layers.prefer-d3d9 = true .
In local build
Last Good: 8e2e52c72e42
First Bad: 4210dd438a36

Triggered by:
4210dd438a36	Joe Drew — Bug 717872 - Store a frame's raw image data pointer beside its imgFrame pointer so we can access it without having to lock the frame. r=seth This patch makes us store imgFrames in FrameBlender with a new sort-of-tuple, FrameDataPair, that is smart enough to be able to lock and unlock imgFrames, and can be transparently cast to an imgFrame, but doesn't do too much else. The alternative, storing a separate array of uint8_t pointers, seemed too complicated.
Aha! The problem is that, since this page is layerized, RasterImage::Draw() is never called. This means that our only way of applying dirt to frame surfaces is bypassed.

However, if we move it to the places that frames are gotten, i.e., GetDrawableImgFrame and ScalingDone, we always hit it when we need to.
Attachment #780557 - Flags: review?(seth)
Comment on attachment 780557 [details] [diff] [review]
apply frame dirt in GetDrawableImgFrame and ScalingDone

Review of attachment 780557 [details] [diff] [review]:

Looks good.
Attachment #780557 - Flags: review?(seth) → review+
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
I can confirm this as working, thanks.
Calling this verified fixed for Firefox 25 based on comment 12.
You need to log in before you can comment on or make changes to this bug.