578514 - Drawing an animated image into canvas does not work

Status: RESOLVED WONTFIX

(Core :: Graphics: ImageLib, defect)

Description

[Jeremie Patonnier :Jeremie]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; en-US; rv:2.0b2pre) Gecko/20100712 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; en-US; rv:2.0b2pre) Gecko/20100712 Minefield/4.0b2pre

With FF4, When you try to draw the frames of an animated image (GIF or APNG) into a canvas object by repeating the drawing operation with setInterval, only the first frame of the image is drawn.

With FF3.6 it works as expected : Mozilla/5.0 (X11; U; Linux i686 (x86_64); fr; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6

 

Reproducible: Always

Steps to Reproduce:
1. Open the test case

Actual Results:  
The image is well animated, but the canvas is not

Expected Results:  
Both image and canvas should be animated

It seems that this behavior has changed since 2009-09-13 (Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20090913 Minefield/3.7a1pre) with the build from http://hg.mozilla.org/mozilla-central/rev/bf0fdec8f43b

Comment 1

[Jeremie Patonnier :Jeremie]

Attachment: testcase

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Hmm, joe?

Comment 3

[Bobby Holley (:bholley)]

This is intended behavior - I added it for canvas spec compliance.

http://hg.mozilla.org/mozilla-central/diff/9f856f094fea/content/canvas/src/nsCanvasRenderingContext2D.cpp#l1.20

http://hg.mozilla.org/mozilla-central/diff/9f856f094fea/content/canvas/test/test_canvas.html

I'm open to adding a flag or something to get non-spec behavior if there's an important use-case. Then again, I'm not the canvas owner.

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Huh, indeed the spec does say that:

> When the drawImage() method is passed an animated image as its image  argument, the user agent must use the poster frame of the animation, or, if there is no poster frame, the first frame of the animation.
>
> When the image argument is an HTMLVideoElement, then the frame at the current playback position must be used as the source image, and the source image's dimensions must be the intrinsic width and intrinsic height of the media resource (i.e. after any aspect-ratio correction has been applied).

That's a bit weird to me; not sure why animated images are treated differently than video.  What do the other browsers do?

Comment 5

[Jeremie Patonnier :Jeremie]

I don't know if there's an important use case here. But in a web designer point of view this behavior is very hard to understand and I agree with Vladimir, the spec is weird here. The main problem to me here is : How is it possible to access the other frames of an animated image? How is it possible to apply some pixel operation on an entire animated image if it's only possible to access the first frame?

Regarding the current state of the spec, it seems that this bug should be mark as WONTFIX. But Do you have any idea if someone at Mozilla could push that use case to the W3C HTML Group?

FWIW Opera 10.60 follow the spec.

Comment 6

[Boris Zbarsky [:bzbarsky]]

I thought the HTML5 spec had a revision log somewhere... would be interesting to look up why it says what it does.

Comment 7

[Bobby Holley (:bholley)]

(In reply to comment #6)
> I thought the HTML5 spec had a revision log somewhere... would be interesting
> to look up why it says what it does.

My guess is that it has something to do with things being deterministic enough to be spec-able. Given all the uncertainty about when the script executes, when the animation timer fires, etc, it seems like the only way to get consistent, definable behavior would be to specify a frame to paint. Once we're doing that, the first frame (or poster frame) seems like a good choice...

Comment 8

[Benoit Girard (:BenWa)]

Wont fix per comment 5.