Add ImageBitmap and related APIs

[autonome]

First take at splitting features out of html, lmk if there's any group we want for that high level.

[captainbrosset]

The impression I get here, and the caveat is I don't this part of the platform well, is that this is more of a reference for the ImageBitmap interface than a developer feature. We need to think of this in terms of what devs would do with it. Are they likely to do new ImageBitmap() and then use the returned object to implement a useful end-user scenario in their web apps? Or would they instead acquire an ImageBitmap object through other means, like when fetching an image, or using a canvas method?

[autonome]

@captainbrosset thanks for the feedback. The high level developer need which the these APIs meet seems mostly around performant/ergonomic transformation/transfer of content.

Image processing, images as sprites, performant duplication/patterns, texture generation, and capturing/moving/modifying frames for anything video/animation.

Example: Say I want to grab some frames from a currently playing video and manipulate them, and/or stash them, then later push to a canvas collage to use as a preview image or whatever.

There's loads of examples of how much fun... er, useful, this is.

The later addition of a global function to create ImageBitmap maybe seems to speak to this being something to file under "Image Processing" or something like that?

From a granularity perspective though, Image Processing seems more like a group than a feature, where ImageBitmap and friends seem more like a feature.

WDYT?

[autonome]

@captainbrosset prompted a conversation on feature composition at the biweekly meeting, which was great! There was no conclusion, but general agreement that the boundaries of a feature are not clear.

Until we get there, I'll instead provide explicit rationale, so that the thinking behind the proposal of a given feature is clear. Perhaps out of this practice, useful criteria may emerge. Maybe we need a concept of a "feature thesis"? 🤔

So in the spirit of EIBTI, writing out the thought process I went through when proposing this as a standalone feature:

• Developer usage: I searched Codepen and Github and a general web search, and it doesn't seem to get lumped into other features. It gets called out by name in a few standalone demos dedicated to it. Code references are often in heavy graphics toolkits (games, 3d, xr) and working with canvas (images in/out).
• No obvious other home: It's an interstitial feature, often used between distinct features such as media elements, canvas. It is most related to Image, but not strictly a subset or different version/flavor of it.
• Specs: The spec authors decided not to hang these APIs off Image, and instead made separate globals.
• Feature prior art: The size and uniqueness of the functionality map reasonably to something groups well together - few methods/properties that stand out as belonging to something else. There are definitely features with far fewer components, and which are related to bigger features.
• Group guidance?: There's no image or related groups, and media-elements isn't right, based on the name and comments there. Other pre-existing groups are a stetch, or not relevant.

Very much open to better ideas, this just seemed sufficient in my first look.

I'm sure we'll come across more "glue" features when breaking up the mega-specs, so more conversation is better since it'll inform those future decisions.

[autonome]

Another option could be to do something around transferables, Image Transfers, rasterization? Something in that direction is a bigger tent to pull the various related svg/canvas/media element APIs into, and a name oriented more around the language of the use-case.

Drawback is that's not really how it is referred to, from what I can see. But feature naming/composition (esp in newer ones) is a balance of status quo and what might make a feature more discoverable/usable.

[autonome]

We discussed in person last week and there were two conclusion-ish things that the assembled group agreed on:

• If an API was created solely as an interchange between other APIs, it does not necessarily mean the API should be a web feature
• If an API has a global constructor, it likely should be a web feature

On the former point, we are still not left with a clear path. Eg API X exists only as way for Feature Y and Z to interact bidirectionally. Does it belong to Feature Y or to Z? 🤷🏽

The latter point is helpful in this particular case, and in our conversation we concluded ImageBitmap should be a feature.

@ddbeck feel free to provide more colour or corrections as needed!

[ddbeck]

OK, forgive me because I don't think I made my point last week very clearly. On the matter of constructors:

The existence of a global constructor strongly implies that there exists a feature, though the interface itself might not be a feature. For example, the MouseEvent() constructor is a clue that there is an event or events feature lurking nearby, but the ability to construct an InputEvent object is probably not, in an of itself, feature-ish. And in such a case, the constructor lives with feature representing the events that can fire.

So my "theory" about interstitial APIs is that they probably came into existence for some concrete feature, then other features co-opted or glommed onto that interface. I have yet to see a counter example yet, though I would be interested to be proven wrong.

So, my chief question is: what was the first API to use an ImageBitmap object? Or did this really come into existence alongside changes to multiple other APIs?

[autonome]

So, my chief question is: what was the first API to use an ImageBitmap object? Or did this really come into existence alongside changes to multiple other APIs?

Probably canvas, as it's the target declared in this language in the spec (even though other targets are valid use-cases also):

An ImageBitmap object represents a bitmap image that can be painted to a canvas without undue latency.

Happy to put this in canvas somewhere if that's what you and @captainbrosset think is best, or elsewhere if you have a suggestion.

[ddbeck]

OK, I dug into this better today. I read the documentation and some specs more closely and trolled through some spec history.

I got my wires crossed and thought this was some sort API interchange type with spotty support, but clearly it's not—it's providing a specific thing back onto canvas, so it doesn't make sense as some kind of later addition. It's its own thing.

I will now be going back on my previous review. 😅

[ddbeck]

Approved, pending a file rename.