W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2013

Re: [whatwg] Adding features needed for WebGL to ImageBitmap

From: Rik Cabanier <cabanier@gmail.com>
Date: Wed, 19 Jun 2013 15:13:23 -0700
Message-ID: <CAGN7qDCPrFY1dZR3EyN9_GPSy8qbdgK_Bt964nimHGFLijg8hg@mail.gmail.com>
To: Gregg Tavares <gman@google.com>
Cc: WHATWG <whatwg@whatwg.org>
On Wed, Jun 19, 2013 at 2:47 PM, Gregg Tavares <gman@google.com> wrote:

> In order for ImageBitmap to be useful for WebGL we need more options
>
> Specifically
>
> premultipliedAlpha: true/false (default true)
> Nearly all GL games use non-premultipiled alpha textures. So all those
> games people want to port to WebGL will require non-premultipied textures.
> Often in games the alpha might not even be used for alpha but rather for
> glow maps or specular maps or the other kinds of data.
>

When would premultipliedAlpha ever be true?
2D Canvas always works with non-premultiplied alpha in its APIs.


>
> flipY: true/false (default false)
> Nearly all 3D modeling apps expect the bottom left pixel to be the first
> pixel in a texture so many 3D engines flip the textures on load. WebGL
> provides this option but it takes time and memory to flip a large image
> therefore it would be nice if that flip happened before the callback from
> ImageBitmap
>

Couldn't you just draw upside down?


>
> colorspaceConversion: true/false (default true)
> Some browsers apply color space conversion to match monitor settings.
> That's fine for images with color but WebGL apps often load heightmaps,
> normalmaps, lightmaps, global illumination maps and many other kinds of
> data through images. If the browser applies a colorspace conversion the
> data is not longer suitable for it's intended purpose therefore many WebGL
> apps turn off color conversions. As it is now, when an image is uploaded to
> WebGL, if colorspace conversion is
> off<
> http://www.khronos.org/registry/webgl/specs/latest/#PIXEL_STORAGE_PARAMETERS
> >,
> WebGL has to synchronously re-decode the image. It would be nice if
> ImageBitmap could handle this case so it can decode the image without
> applying any colorspace manipulations.
>

Shouldn't the color space conversion happen when the final canvas bit are
blitted to the screen?
It seems like you should never do it during compositing since you could get
double conversions.


>
> If it was up to me I'd make createImageBitmap take on object with
> properties so that new options can be added later as in
>
>     createImageBitmap(src, callback, {
>        premultipliedAlpha: false,
>        colorspaceConversion: false,
>        x: 123,
>     });
>
> But I'm not familiar if there is a common way to make APIs take a options
> like this except for the XHR way which is to create a request, set
> properties on the request, and finally execute the request.


 Like Tab said, it's fine to implement it that way.
Be aware that you might have to do some work in your idl compiler since I
*think* there are no other APIs (in Blink) that take a dictionary.
Received on Wednesday, 19 June 2013 22:13:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:22 UTC