[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Adding internalformat param to all texImage2d variants
----- "Kenneth Russell" <firstname.lastname@example.org> wrote:
I suggest that the best path forward might be to leave the signatures
of the texImage2D and texSubImage2D helpers taking DOM elements as
they are currently. Not adding an internalformat argument would make
it easier to add overloads later which have either this argument or
both internalformat and type arguments. We can tighten up the
specification of the current entry points to guarantee their behavior
What are your thoughts?
I agree with this. I'll also point out that ArrayBuffer should be showing up on XMLHttpRequest/File API/etc. very soon (certainly in the same timeframe as WebGL 1.0, I'd guess), and that provides an alternate path for applications that wish to load single channel, N-channel, or other images. They can be fetched via XHR as RLE-compressed targa or some other format, and never have to go through the browser's mechanisms for image handling. It becomes difficult to handle, say, jpeg images as RGB or 1- or 4-channel PNG images, since that would require writing the decoder in JS, but I think that the use of those formats for non-3/4-channel data is probably not that common. With regards to RGB instead of RGBA, we've been kicking around the idea of adding a way to get the RGBA bytes as an ArrayBuffer from any HTML image element (image.imageData, say); an app could do the packed-pixel conversion itself on load and then release the original HTML image element and just hold on to a 3-channel packed ArrayBuffer. So, there should be various ways around these problems for WebGL 1.0.