[blink-dev] Intent to Ship: ImageBitmapOptions

[Xida Chen]

Contact emails

xida...@chromium.org, ju...@chromium.org, k...@chromium.org

Spec

https://html.spec.whatwg.org/#imagebitmapoptions

Summary

ImageBitmapOptions provides control over the decoding process when creating ImageBitmaps, especially from image files like PNG and JPEG.

It is essential in order to asynchronously create ImageBitmaps for use with the WebGL API, since the images will be decoded in exactly the desired form. This will speed up texture handling for applications like Google Maps in the browser though code changes are needed to take advantage of it.

Link to “Intent to Implement” blink-dev discussion

https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Feb/0008.html

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

The WebGL conformance tests at https://github.com/KhronosGroup/WebGL already contain exhaustive tests for this feature. It is currently available behind the --enable-experimental-canvas-feature flag.

Debuggability

This feature does not require special debugging support on its own.

Interoperability and Compatibility Risk

Interoperability risk is low. Firefox has shipped ImageBitmap. Other browsers have no public signals yet. Compatibility risk is low, as this does not remove or change existing features.

OWP launch tracking bug

http://crbug.com/249382

Entry on the feature dashboard

https://www.chromestatus.com/features#imagebitmapop

[Rick Byers]

Looks reasonable to me, just want to understand the interop risk a bit better:

On Fri, Apr 15, 2016 at 7:22 AM, Xida Chen <xida...@chromium.org> wrote:

Contact emails

xida...@chromium.org, ju...@chromium.org, k...@chromium.org

Spec

https://html.spec.whatwg.org/#imagebitmapoptions

Summary

ImageBitmapOptions provides control over the decoding process when creating ImageBitmaps, especially from image files like PNG and JPEG.

It is essential in order to asynchronously create ImageBitmaps for use with the WebGL API, since the images will be decoded in exactly the desired form. This will speed up texture handling for applications like Google Maps in the browser though code changes are needed to take advantage of it.

Link to “Intent to Implement” blink-dev discussion

https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Feb/0008.html

Looks like there was no "intent to implement" on blink-dev.  That's fine, this thread can be considered an "implement and ship". 

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

The WebGL conformance tests at https://github.com/KhronosGroup/WebGL already contain exhaustive tests for this feature. It is currently available behind the --enable-experimental-canvas-feature flag.

Debuggability

This feature does not require special debugging support on its own.

Interoperability and Compatibility Risk

Interoperability risk is low. Firefox has shipped ImageBitmap.

Has there been any discussion about implementing ImageBitmapOptions in Gecko?  At a quick glance, I can't find any bugzilla bugs for it (you could file one to spark discussion), and I don't see any code there yet either.  Whenever we're first to ship an API, the interoperability risk is non-trivial.  Just wondering what signals we have about the suitability of the API for other implementations (since there's a bunch of implementation-defined details in the graphics stack here).  Has any other vendor provided input on the API design? 

[Justin Novosad]

On Sun, Apr 17, 2016 at 11:16 PM, Rick Byers <rby...@chromium.org> wrote:

Has there been any discussion about implementing ImageBitmapOptions in Gecko?  At a quick glance, I can't find any bugzilla bugs for it (you could file one to spark discussion), and I don't see any code there yet either.  Whenever we're first to ship an API, the interoperability risk is non-trivial.  Just wondering what signals we have about the suitability of the API for other implementations (since there's a bunch of implementation-defined details in the graphics stack here).  Has any other vendor provided input on the API design? 

I looked at discussion archives. People from Mozilla have commented on the feature proposal, but nothing as strong as an intent to implement was ever expressed publicly AFAICT. I will reach out.

[Kenneth Russell]

Thanks Justin for reaching out to their development team.

Rick, there have been discussions in the WebGL working group about this feature, and I can say there is general agreement that this API is the desired direction for all browsers in order to reduce the cost of uploading images to WebGL textures. However, there aren't any public statements to that effect at this point.

-Ken

[Mike Lawther]

This is a pretty common state of affairs across working groups :/

Xida mentions in the original post that there are exhaustive tests for this feature in the conformance tests. Does that lend weight to the general agreement in the discussions (eg if they were reviewed by other vendors?). 

[Rick Byers]

Yep, makes sense.  We don't block shipping on the absence of feedback, just on legitimate outstanding concerns and the absence of attempts to solicit feedback.  It sounds like there's been some good discussion without any serious concerns, plus it's a small API so the risk isn't great.  So LGTM1.  But please ping this thread if substantial new concerns are raised.

[Kenneth Russell]

It does. Chrome's a bit farther ahead than the other WebGL implementers in passing these ImageBitmap tests (thanks to hard work by Xida and others), but in coming weeks and months I expect they'll start looking at them and passing them too.

-Ken

[Philip Jägenstedt]

For premultiplyAlpha and colorspaceConversion, the "default" values have implementation-specific behavior. What will they do in Blink's implementation? (I'm guessing there's a good reason for having implementation-specific behavior, just doing a sanity check.)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Xida Chen]

Hi Phillip,

In the spec, the "default" option is provided so that different browsers could have different implementation for optimization purpose, such as efficiency, memory and so on. In Blink, premultiplyAlpha = default means that premultiplyAlpha is applied, and colorspaceConversion = default means that color profile is applied. 

[Philip Jägenstedt]

Thanks Xida! It would be interesting to see if any other browser makes a different choice, or if default will in fact end up as an interoperable alias for something else. LGTM3, hope it works out!

[Xida Chen]

I believe that's actually the second LGTM, so this still needs another one.

[Philip Jägenstedt]

Oops, sorry :)

[Justin Novosad]

To add to Xida's explanation of default behaviors: In Safari's implementation, colorspaceConversion = default will most likely mean "convert to sRGB". This is because Safari uses the sRGB colorspace for canvases, so converting to sRGB would be the optimal conversion for that implementation.  In chrome, canvas contents are not currently color-corrected, so the canvas drawing drawing buffers are effectively in the display's colorspace, which is why our default colorspace conversion behavior is to apply the display profile.

[Philip Jägenstedt]

Thanks Justin, that makes sense, and means that there will be an actual difference in default behavior, so the extra enum value isn't wasted :)

[Jochen Eisinger]

lgtm3