For the record, the WebGL working group would like to see this option in the spec.

What's the script-visible effect here?

It seems like ImageData can already store its data internally however it wants, and can already remember whether its backing store is premultiplied or not, so when it reaches another API it can avoid unnecessary conversions.  For example, if an ImageData is created from a premultiplied canvas and then loaded into a WebGL texture with UNPACK_PREMULTIPLY_ALPHA_WEBGL set, it can avoid doing any extra premultiplication and un-premultiplication passes.

This would be an optimisation hint only. It would enable a browser to set up the pixel data as required for future use before it is used, so that future use can happen faster.

What would be helpful for spec purposes is if someone could list all the places you can use ImageBitmap, and describe whether that place would prefer premultiplied data or straight data.

There is desire to implement this feature on the Google Chrome team. Having it specified would make it easier to motivate adding it.

In reply to the comment above, in the WebGL specification, ImageBitmap could be uploaded to texImage2D and texSubImage2D. The intent would be that the ImageBitmap would be uploaded to the texture with exactly the parameters desired, overriding the WebGL-specific pixel storage parameters like UNPACK_PREMULTIPLY_ALPHA_WEBGL described in http://www.khronos.org/registry/webgl/specs/latest/1.0/#6.8 . With this and the other proposed arguments to createImageBitmap, the ImageBitmap would be decompressed into exactly the desired form, avoiding a redundant decompression during the synchronous texImage2D and texSubImage2D calls.

So basically the WebGL spec will be updated to say that if an ImageBitmap is passed, and it was created with these configuration options specified, the data will be used as-is, ignoring the pixel storage parameters?

(In reply to Ian 'Hixie' Hickson from comment #5)
> So basically the WebGL spec will be updated to say that if an ImageBitmap is
> passed, and it was created with these configuration options specified, the
> data will be used as-is, ignoring the pixel storage parameters?

Even more strongly: the WebGL spec will say (I think) that if ImageBitmap is passed then its data will always be used as-is, ignoring WebGL's pixel storage parameters, regardless of whether these configuration options were set. The defaults will take effect if they were not.

(In reply to Kenneth Russell from comment #6)
> (In reply to Ian 'Hixie' Hickson from comment #5)
> > So basically the WebGL spec will be updated to say that if an ImageBitmap is
> > passed, and it was created with these configuration options specified, the
> > data will be used as-is, ignoring the pixel storage parameters?
> 
> Even more strongly: the WebGL spec will say (I think) that if ImageBitmap is
> passed then its data will always be used as-is, ignoring WebGL's pixel
> storage parameters, regardless of whether these configuration options were
> set. The defaults will take effect if they were not.

Ian's "hinting" approach seems better to me.

Today, if you don't care about premultiplication (and possibly having slower texture loads), you just leave UNPACK_PREMULTIPLY_ALPHA_WEBGL off.  You get an un-premultiplied texture, and you don't have to do anything else.  If you want to render it with simple transparency, you just set the usual (SRC_ALPHA, ONE_MINUS_SRC_ALPHA) blend function.

If the type of the ImageBitmap determines the texture, that means that if you're handed an ImageBitmap from an external source and you load it into a texture, you might get a premultiplied texture.  Suddenly, people need to adjust their rendering to support premultiplied ImageBitmaps (eg. changing SRC_ALPHA to ONE if the input is premultiplied), where before you could treat an ImageBitmap as a generic, opaque bitmap.

By making the ImageBitmap mode a hint--saying "I expect to want this data in premultiplied form"--the factors that dictate what type of texture you get remain where they are, within WebGL.  Developers that want extra performance or accuracy can set the hint, but it doesn't make things more complicated when you don't.

If you really need it, you could have a new unpack setting, eg. UNPACK_PREMULTIPLY_ALPHA_WEBGL = FASTEST, to say "use the value of the ImageBitmap's hint, if it has one".  That would let developers give a fast path no matter what hint was given, while not making things harder for the common case where you really just want a specific texture type.

I don't think that's a good approach. From the standpoint of the WebGL specification, we never want to re-decode an ImageBitmap representing an HTMLImageElement when it's uploaded via texImage2D or texSubImage2D. The desire is to have all of the configuration options specified at ImageBitmap creation time, and not to have to do more decoding work after the Promise is fulfilled.

I tried to give some specific reasons why I think Ian's approach seems preferable, including a way to do what you described ("just follow the hint") within that framework if you want to.  So, please don't reply by just saying "that's not what we desire".

I replied to the points given. Treating the flag as a hint will lead to subtle performance problems. The entire point of using ImageBitmap with WebGL is to solve longstanding performance problems when uploading HTML images to WebGL textures.

It would be better from a developer's standpoint to see their rendering code break when they switch to loading their textures via ImageBitmap, fix the creation options, and get better performance. The alternative is that the developer switches to loading their texture resources via ImageBitmap, see no performance improvement, and wonder why. For this reason I won't support adding an UNPACK_PREMULTIPLY_ALPHA_WEBGL = FASTEST option to the WebGL spec.

I replied to the points given. Treating the flag as a hint will lead to subtle performance problems. The entire point of using ImageBitmap with WebGL is to solve longstanding performance problems when uploading HTML images to WebGL textures.

It would be better from a developer's standpoint to see their rendering code break when they switch to loading their textures via ImageBitmap, fix the creation options, and get better performance. The alternative is that the developer switches to loading their texture resources via ImageBitmap, see no performance improvement, and wonder why. For this reason I won't support adding an UNPACK_PREMULTIPLY_ALPHA_WEBGL = FASTEST option to the WebGL spec.

(In reply to Kenneth Russell from comment #11)
> I replied to the points given. Treating the flag as a hint will lead to
> subtle performance problems. The entire point of using ImageBitmap with
> WebGL is to solve longstanding performance problems when uploading HTML
> images to WebGL textures.

No, the performance implications are identical in both cases.  Either way, the underlying storage of the ImageBitmap is an opaque implementation detail and it may perform any number of conversions.

> It would be better from a developer's standpoint to see their rendering code
> break when they switch to loading their textures via ImageBitmap, fix the
> creation options, and get better performance.

No, that's not always better.  Very often the performance of creating textures is irrelevant, and what you want is to be able to create a texture in a predictable format given an arbitrary ImageBitmap.  Don't force people to care about performance optimizations when they have no reason to.

> The alternative is that the
> developer switches to loading their texture resources via ImageBitmap, see
> no performance improvement, and wonder why. 

Switches from what?  If you're coming from an HTMLImageElement or an HTMLCanvasElement, there's no reason to expect routing through an ImageBitmap to be faster, and it definitely shouldn't be.

> For this reason I won't support
> adding an UNPACK_PREMULTIPLY_ALPHA_WEBGL = FASTEST option to the WebGL spec.

It would be helpful if you'd make up your mind after discussion, rather than before.

https://github.com/whatwg/html/pull/741