Re: [w3ctag/design-reviews] Request to review Image Decode API (#182)

> Where does the spec say this? To me, the current spec text seems to say the opposite, since it says:

You're right that this is unclear in the spec. The text is really only talking about static images and the only reference to animated images is in the note, which hints at the fact that although the first frame could be already decoded, all frames should be available. @domenic, do you think we could elaborate on animated images more?

> Also, is it possible for the current frame of an animated image to change between the call to decode() and the "end of the next update the rendering step in the event loop"? If so, which frame should be guaranteed to be decoded?

This is unspecified... It seems a bit like a misuse of the API, since the point at which the frames advance in an animated image is outside of the author's control. It seems similar to calling a decode() on a static image that is already displayed on the screen. At that point, the decode is not necessary, since the image is already rasterized on screen. Similarly, when an animated image is in the dom, the implementers have full knowledge of what frames are expected to appear and when they need to appear so calling decode on it is questionable. To put it differently, it's not clear to me what reasonable action the author can take in the promise resolution callback that would aid the browser in ensuring frames appear quickly.

FWIW, a possible implementation could decode the current frame at the time of the decode() call, whether or not that's the frame that is current at the time of the promise resolution.

The intent of the API, which is what the examples demonstrate, is to give the authors tools to "prepare" the image before inserting it into the dom; to indicate to the browser that this image is about to be in a state that needs to be rasterized. For animated images outside of the dom, this means the first frame needs to be decoded. For animated images in the dom, the browser has more knowledge than the author about which frames need to be rasterized.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/182#issuecomment-313743393