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

To your first point:

With encoded images, every implementation needs to have a decoding step. Some implementation defer this decode until the image needs to be displayed (such as the case in Chrome and Safari for example). In those situations this API provides a good hint to the implementer that the image needs to be displayed soon, so it's a good signal to start the decode now and issue a callback when that's done. If implementations exists that do the decode at the time of rasterizing the content (ie no caching happens), then this provides a hint that could technically be ignored, although it might help prioritizing which decode needs to happen sooner rather than later.

For the animated case, the requirement is that the frames are available but not necessarily that they need be decoded. That is, essentially "onload" has to fire and then the first frame of the animated image is decoded before the callback is issued. Calling this API does not require that every frame needs to be decoded, for the reasons that you mention (it may not feasible in low memory situations).

I'll defer to @domenic for the second point.

-- 
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-313245241

Received on Wednesday, 5 July 2017 22:33:48 UTC