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

I'm sorry that this thread went off-track. Chromium has a similar [code of conduct](https://chromium.googlesource.com/chromium/src/+/master/CODE_OF_CONDUCT.md) and we take it seriously. Hopefully we can get past this and get the discussion back on track.

-----

The reason we propose this method be called "decode" is simply because that's the main operation that it performs. This is separate from any other possible operation such as layout or rasterization. It prepares the image content into a format suitable for rasterization (a.k.a. decode). It is true that it also implies a load, but that's an ergonomics issue. Decoding a partial image which is in the process of being loaded is often times wasted work, since the decode is essentially invalidated by the next packet of data received. It's certainly reasonable to say that a decode should be issued from an onload handler to avoid this. We decided against this, because requesting a decode on an image that isn't loaded is likely not the intent of the developer. To put it differently, it's very unlikely that the developer really did intend to call a decode on a partially loaded image. Thus, bundling this seemed like an elegant solution to avoid any foot-guns.

The problem that I see with something like "ready" is that it is less precise. It's unclear from the name alone what readiness of an image means. Could it mean layout and rasterization as well? Or could it simply be equivalent to just load? Additionally, a decode is understood (and specced) to be available for the next raf. After that, it may be evicted from any decoding caches. With a ready signal, it's harder to argue or understand that an image is ready one frame but may become not ready in the next few frames. Adding something like a "ready attribute" to indicate whether the image is available is hard, since the pipeline is typically decoupled. That is, keeping the ready attribute in sync with the decoding caches can be inefficient and prone to errors.

As mentioned previously, this is an action on HTMLImageElement.prototype. As such it's independent of any separate future features, such as a Decoder which would presumably have its own set of functions named appropriately for the work that it does. 

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