- From: Rik Cabanier <cabanier@gmail.com>
- Date: Wed, 19 Jun 2013 16:03:33 -0700
- To: Gregg Tavares <gman@google.com>
- Cc: WHATWG <whatwg@whatwg.org>
On Wed, Jun 19, 2013 at 3:24 PM, Gregg Tavares <gman@google.com> wrote: > > > > On Wed, Jun 19, 2013 at 3:13 PM, Rik Cabanier <cabanier@gmail.com> wrote: > >> >> 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. >> > > AFAIK the canvas API expects all images to be premultiplied. Certainly in > WebKit and Blink images used in the canvas and displayed in the img tag are > loaded premultiplied which is why we had to add the option on WebGL since > we needed those images before they had lost data. > > >> >> >>> >>> 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? >> > > No, games often animate texture coordinates and other things making it far > more complicated. There are ways to work around this issue in code yes, > they often require a ton of work. > > Most professional game engines pre-process the textures and flip them > offline but that doesn't help when you're downloading models off say > http://sketchup.google.com/3dwarehouse/ > > >> >> >>> >>> 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 >>> >, >> >> OK, I see what you're trying to accomplish. You want to pass non-premultiplied data and color converted (from sRGB to monitor) pixels to WebGL I think your API looks fine, except that the defaults should all be false... > >>> 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. >> > > Maybe but that's not relevant to ImageBitmap is it? The point here is we > want the ImageBitmap to give us the data in the format we need. It's > designed to be async so it can do this but it we can't prevent it from > applying colorspace conversions. > Some browsers did that for regular img tags which pointed out the original > problem. The browser can't guess how the image is going to be used and > since it's a lot of work to decode an image you'd like to be able to tell > it what you really need before it guesses wrong. > > >> >> >>> >>> 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 23:03:58 UTC