[whatwg] Adding features needed for WebGL to ImageBitmap

Kenneth Russell kbr at google.com
Wed Jul 10 17:32:31 PDT 2013

On Wed, Jul 10, 2013 at 5:13 PM, Peter Kasting <pkasting at google.com> wrote:
> On Wed, Jul 10, 2013 at 5:07 PM, Ian Hickson <ian at hixie.ch> wrote:
>> (The other two options don't make much sense to me even for GL. If you
>> don't want a color space, don't set one. If you don't want an alpha
>> channel, don't set one. You control the image, after all.)
> I only have a small amount of graphics experience, but I don't think that
> latter comment is right, at least.
> At least for the alpha channel, as Gregg already wrote, a lot of GL
> algorithms use that data for something per-pixel that's not "alpha"
> (generally some other kind of per-pixel map).  It's not appropriate for the
> browser to assume that it's safe to muck with the values there.  Fixing this
> by instead trying to pass these values separate from the rest of the pixel
> data is inefficient as well as just weird from the perspective of anyone
> with significant experience in using these sorts of algorithms.

This is correct. Further, even if an image doesn't contain any color
space information, the browser may still incorrectly decide to adjust
the colorspace of decoded image data based on the client machine's
settings. It's required to be able to tell the browser to not do this.

I would find it really discouraging if the WebGL spec had to subsume
image loading functionality. It's a statement of fact that with a
dictionary of options, ImageBitmap can work as efficiently for the
WebGL canvas context as it's intended to for the 2D canvas context.


More information about the whatwg mailing list