Add a call-out to Web Codecs API during decoding #1018
Conversation
| } | ||
| // If none of those work, let’s see if Web Codecs API is available | ||
| if (await WebCodecs.isTypeSupported(mimeType)) { | ||
| return await abortable(signal, WebCodecs.decode(blob, mimeType)); |
There was a problem hiding this comment.
I am not returning to the hail-mary path below because Web Codecs API will support all the image formats that built-in canvas supports.
There was a problem hiding this comment.
Just a slight caveat there, we don't support ICO/CUR and SVG presently. SVG requires DOM, so can't be done in a worker context. ICO/CUR function oddly so we've disabled support in the mean time. Either way the isTypeSupported() will give you a valid answer.
There was a problem hiding this comment.
Are there any other differences we should be aware of vs createImageBitmap?
There was a problem hiding this comment.
@surma shouldn't this code be rolled into builtinDecode? Since it's using the built-in decoders
There was a problem hiding this comment.
It feels too early to land this since it's an evolving API (the demos in https://twitter.com/ChromiumDev/status/1255870582442405889 no longer work) and there isn't a spec yet.
Should we make this a draft?
|
Oh I thought this was stable-ish. Yeah, happy to let this sit for a while then. |
|
ImageDecoder is now stable (updates were tracked here: https://bugs.chromium.org/p/chromium/issues/detail?id=1182435). I've ping @tomayac about updating the demo. The spec is here https://w3c.github.io/webcodecs/#image-decoding |
✅ Demo updated: https://imagedecoder.glitch.me/. |
|
@dalecurtis my bad. Maybe update https://github.com/dalecurtis/image-decoder-api? That page has good SEO 😀 and there's no link to the spec. |
|
Ah! I thought I had already done that, thanks for calling that out. Done. |
|
I've got a vague worry that we're moving from an API where the mimetype doesn't need to be accurate, to one where it does. Like, in Squoosh right now we could remove a bunch of our mime sniffing code, since we only need to sniff for the encoders we ship. However, with this PR, we can't do that, as Chrome would no longer be able to load a Maybe it's fine. I'm just worried about adding the complexity for little/no gain. In future this would let us support animated formats though, which is nice. |
|
Would you prefer if we continued to fall through to the hail-mary canvas decoding when WebCodecs fails? |
|
Yeah let's do that for safety, just in case it turns out our WebP sniffing is wrong for some exotic flavour of WebP or whatever. We should keep our current set of file sniffing, as we'd need it if we wanted to support animated types. |
|
Filed w3c/webcodecs#252 |
|
Done! |
|
I still think this code should go in |
|
Done. I added a couple of aborted checks to avoid unnecessary work. Is that the idiomatic way to do that with |
Co-authored-by: Jake Archibald <[email protected]>
Co-authored-by: Jake Archibald <[email protected]>
|
I've filed #1028 for me to do something better for abortables |
|
@jakearchibald WDYT about having AbortSignal as a second parameter to decode()? (In the standard) Or as a member in the ImageDecodeOptions dictionary. |
|
I know you didn’t ask me, but considering that even decoding can take any amount of time in the context of WebCodecs (as we don’t curate the codecs anymore), that seems like a very good idea to me. |
|
All opinions welcome :) Filed w3c/webcodecs#254 |
Added a code path that uses Web Codecs API during decoding.