- From: Kenneth Russell <kbr@google.com>
- Date: Wed, 10 Jul 2013 17:32:31 -0700
- To: Peter Kasting <pkasting@google.com>
- Cc: WHATWG <whatwg@whatwg.org>, Rik Cabanier <cabanier@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Ian Hickson <ian@hixie.ch>
On Wed, Jul 10, 2013 at 5:13 PM, Peter Kasting <pkasting@google.com> wrote: > On Wed, Jul 10, 2013 at 5:07 PM, Ian Hickson <ian@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. -Ken
Received on Thursday, 11 July 2013 00:32:57 UTC