[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebGL in Workers

On Thu, May 3, 2012 at 8:53 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
We don't really need HTMLImageElement in workers.  The only places where WebGL takes an HTMLImageElement one can pass the corresponding ImageData.  We could add some sort of convenience function for getting said ImageData out of an HTMLImageElement, if desired, to avoid having to roundtrip through a 2d canvas context.

Alternately, in the interests of efficiency, we could make it possible to pass an HTMLImageElement to a worker and get an opaque thing that represents its data (actual data plus format information) to avoid forcing conversions to RGBA.

I think the latter is much better.  In particular, browsers tend to put off decompressing the image data until you actually use it, and once it happens, it tends to happen synchronously (since a drawImage+getImageData is inherently synchronous).  PNGs are pretty expensive to decompress, so this can lead to significant hitching in the UI thread.  The latter approach can avoid that problem.  (It might even allow decompressing the image in its own thread as part of creating the texture, which could make loading lots of big textures from PNGs faster.)

Also, while this isn't strictly needed, it would be a big plus if WebGL in workers can load its own data, instead of having to load the images in the main thread and then hand them off.  Having to ask the main thread to do that for you is pretty cumbersome.  Maybe it could be done as an XHR mode, which--in terms of the above approach--would return the opaque data that you would have received if you had loaded the HTMLImageElement and pulled it from there.

Glenn Maynard