Intent to Ship: The ImageBitmap rendering context for <canvas>

[Justin Novosad]

Contact emails

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

Spec

https://html.spec.whatwg.org/multipage/scripting.html#the-imagebitmap-rendering-context

https://github.com/w3ctag/spec-reviews/issues/141

Summary

ImageBitmapRenderingContext is a performance-oriented interface that provides a low overhead method for displaying the contents of ImageBitmap objects. It uses transfer semantics to reduce overall memory consumption. It also streamlines performance by avoiding intermediate compositing, unlike the drawImage() method of CanvasRenderingContext2D.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/OffscreenCanvas%7Csort:relevance/blink-dev/ckHvzFXn5zQ/ZkzPC--gAgAJ

Note: ImageBitmapRenderingContext was originally a componenet of the larger OffscreenCanvas feature proposal. Since it has merit as a standalone feature we intent to ship ImageBitmapRenderingContext first.

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

Yes

Interoperability and Compatibility Risk

No interference with pre-exisitng APIs.

There is an interoperability risk with Firefox because they accidentally shipped this API with the wrong method name (transferImageBitmap instead of transferFromImageBitmap). They filed an issue against the spec to have the API changed to match their name before other browsers shipped the feature. The issue was closed without resolving. We're assuming that means Firefox with change the name (or create an alias) to match the spec.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=658734

Entry on the feature dashboard

https://www.chromestatus.com/feature/5709799995998208

[Kenneth Russell]

Eager to see this ship! It enables some important customer use cases for both single-threaded performance as well as multithreaded rendering.

[Philip Jägenstedt]

On Mon, Oct 24, 2016 at 5:41 PM Justin Novosad <ju...@chromium.org> wrote:

There is an interoperability risk with Firefox because they accidentally shipped this API with the wrong method name (transferImageBitmap instead of transferFromImageBitmap). They filed an issue against the spec to have the API changed to match their name before other browsers shipped the feature. The issue was closed without resolving. We're assuming that means Firefox with change the name (or create an alias) to match the spec.

It looks like https://github.com/whatwg/html/issues/1818 was that issue.

The Gecko change has already been done, so at this point that's the way to go, but in general I think that we should be quite willing to change specs and not-yet-shipping implementations to match what others have shipped, even if accidental.

I poked around the IDL a bit, there's not much of it, and I see there are tests for both { alpha: true } and { alpha: false }.

LGTM1

[Boris Zbarsky]

On 10/24/16 11:41 AM, Justin Novosad wrote:
> There is an interoperability risk with Firefox because they accidentally
> shipped this API with the wrong method name (transferImageBitmap instead
> of transferFromImageBitmap). They filed an issue against the spec to
> have the API changed to match their name before other browsers shipped
> the feature. The issue was closed without resolving. We're assuming that
> means Firefox with change the name (or create an alias) to match the spec.

To correct the history here: Firefox checked in
ImageBitmapRenderingContext in
https://bugzilla.mozilla.org/show_bug.cgi?id=1172796 back in December
2015 and shipped it in Firefox 46 on April 26, 2016.

The spec was changed from "transferImageBitmap" to
"transferFromImageBitmap" on April 22, 2016 in
<https://github.com/whatwg/html/commit/fcb0756dd94d96df9b8355741d82fcd5ca0a6154>
based on pull request https://github.com/whatwg/html/pull/1101 which was
created on that same day. Note that this was 4 days before the Firefox
46 release date, and past the code freeze for the release. The
discussion in the pull request indicates that it was known that Firefox
was already shipping the current state of the spec and the spec was
changed anyway. There was no corresponding issue filed on Firefox until
_September_ 2016....

So it's not that Firefox accidentally shipped the wrong name. It's that
the name got changed after Firefox had already shipped it.

Anyway, Firefox is in fact planning to ship both names as aliases in
Firefox 50. See <https://bugzilla.mozilla.org/show_bug.cgi?id=1304767>.

The "transferImageBitmap" name is still supported, but with a
deprecation message and a use counter. We'll see what that shows and
remove it when we can, I guess.

-Boris

[Philip Jägenstedt]

Thanks Boris. Somewhat surprising is the "I'm fine with this" from what appears to be the Gecko implementer. What was the "experimental disclaimer" mentioned?

(We're still experimenting, but I hope that tests (run on stable and nightly builds) and implementation bugs will make the shipping status more obvious and that the bar for changes is higher after shipping, although not infinitely high.)

[Boris Zbarsky]

On 10/24/16 3:51 PM, Philip Jägenstedt wrote:
> Thanks Boris. Somewhat surprising is the "I'm fine with this

> <https://github.com/whatwg/html/pull/1101#issuecomment-213471093>" from

> what appears to be the Gecko implementer.

Yeah, I have no idea what that was about and why there was no
corresponding bug filed and fixed that day, so we would ship the alias
earlier than Firefox 50. :(

> What was the "experimental disclaimer" mentioned?

I have no idea. Maybe it was documented as "experimental" on MDN or
something, but of course no one would notice that in practice. The IDL
certainly has no experimental anything, nor does the impl at first glance.

-Boris

[Anne van Kesteren]

On Mon, Oct 24, 2016 at 9:57 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> Yeah, I have no idea what that was about and why there was no corresponding
> bug filed and fixed that day, so we would ship the alias earlier than
> Firefox 50. :(

Slightly off-topic, but I wonder what's preferable when we make
changes to standards. Updated tests or bugs whenever we make a change
to something that's implemented? We prioritized tests, but I'm having
the feeling that bugs might have more of an impact. Although it
depends of course when they're acted upon.


--
https://annevankesteren.nl/

[Rick Byers]

I agree with Philip that the pragmatic reality of what the web has already come to depend on matters more than preference for ideal names.  We definitely can't complain about Firefox shipping based on an earlier version of the spec when we do that all the time :-).

Boris / Olli, would you like to re-visit the decision to change the name?  Seems like there's still a chance to revisit that if you think it's the better course of action.  Do you have any usage data on the original API? If it turns out that usage of the old name is high enough that Firefox can't remove it, then there's a chance we'd end up wanting an alias eventually too (for maximum interop / site compat).

Rick

[Boris Zbarsky]

On 10/25/16 3:31 AM, Anne van Kesteren wrote:
> Slightly off-topic, but I wonder what's preferable when we make
> changes to standards. Updated tests or bugs whenever we make a change
> to something that's implemented?

In an ideal world, I think it would be:

1) Updated tests.
2) Browsers syncing to upstream tests often.
3) Browsers filing bugs during the sync process when
a failing upstream test comes in, or a previously
passing test starts to fail.

We have #2 in Firefox but not #3. I've been pushing for it, but
progress has been slow. :( As a result, no one notices when updated
tests happen, unfortunately.

So for the moment, bugs are probably more useful in terms of getting
Firefox to align with spec changes. Updated tests would save the
engineer fixing the bug the work of writing tests of course. ;)

But really, we should get #3 happening.

Obviously, updated tests are much better than nothing, and are a good
habit to get into for the long-term future, per above.

-Boris

[Boris Zbarsky]

On 10/25/16 9:31 AM, Rick Byers wrote:
> Boris / Olli, would you like to re-visit the decision to change the
> name?

I don't have a strong opinion, honestly; I haven't thought in depth
about this specific API.

I do expect usage to be low, based on it being only recently added and
no one else shipping it.

> Do you have any usage data on the original API?

Sort of. The use counter has been in place on nightly for about two
weeks. It's been in place on devedition and beta for a week, but I'm
not sure whether that's actually been shipped out to users yet. So I do
not trust any numbers from it, not at all. A few weeks from now I'll
trust them a lot more.

With that caveat, we've had 0 hits on this use counter so far.

> If it turns out that usage of the old name is high enough
> that Firefox can't remove it

I would be somewhat surprised if this turns out to be the case.

-Boris

[smaug]

On 10/25/2016 05:00 PM, Boris Zbarsky wrote:
> On 10/25/16 3:31 AM, Anne van Kesteren wrote:
>> Slightly off-topic, but I wonder what's preferable when we make
>> changes to standards. Updated tests or bugs whenever we make a change
>> to something that's implemented?
>
> In an ideal world, I think it would be:
>
> 1) Updated tests.

This should also include running tests on browsers, since then in an ideal world we'd catch sooner when there will
be breaking changes in specs, and spec's would hopefully have fewer regressions. Kind of a variant of 3) but just happening asap.
I thought there has been some plans to get this done.

-Olli

[Justin Novosad]

Right. We have a bunch of tests we should upstream to web-platform-tests ASAP. 

[Rick Byers]

Ok, thanks everyone for the good discussion.  Sounds like shipping this is the right next step.  LGTM2 to ship.

Separately there's lots of good learning here for our interop efforts.  We're doing a variety of things to try to make the workflow Boris describes easy for blink engineers (easy updating web-platform-tests, regular sync, semi-automatic bug filing for new failures in areas teams have opted into, etc.).

Rick

[TAMURA, Kent]

LGTM3 to ship.

--
You received this message because you are subscribed to the Google Groups "platform-predictability" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-predictability+unsub...@chromium.org.
To post to this group, send email to platform-predictability@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-predictability/CAFUtAY9RpgRzbL%3DvBqsVQtaKPvaeeTiZDY1kLDmOBcxzJ2XN-Q%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google