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

Re: [Public WebGL] Adding internalformat param to all texImage2d variants



On 2010-05-20 11:14, Cedric Vivier wrote:
On Thu, May 20, 2010 at 16:25, Tim Johansson<timj@opera.com> wrote:
Imho this is a problem in both lack of specification and inefficient
texture memory usage by WebGL (just saving RGB DOM images with RGB
internal format gives 25% texture memory savings for free, a saving
quite significant on limited texture memory/bandwidth devices).
I agree, but if the price we have to pay for that memory saving is
incompatibilities I don't think it's worth it.
Do you have any incompatibility in mind other than the slight
potential issue with few specific combinations on top of Direct3D I
mentioned ?

The main one I can think about is the potential FBO one, see more about that below.

(the issue can be totally avoided by disabling conversion on the
troublesome combinations when running on top of D3D, the relative
inefficiency of the workaround is mitigated by the fact these few
combinations are rare and that D3D is not typically used on devices as
bandwidth-constrained as ES's)


How about binding a texture created from an HTML image to a framebuffer?
I've never actually bound anything that was not RGBA to a framebuffer so I'm
not sure what will happen, but I assume it can cause incompatibilities.
ES section 4.4.7 second paragraph defines conversion takes place.
The conversions rule used are once again the same as in the conversion
table proposed, ie. ES table 3.12, GL tables 3.11 and 3.20 (or 3.20/23
depending spec version).

So if you create a texture from an Image object, then bind it to and FBO and render full RGBA data to it the result will be different depending on the internal format?
If the original image was RGB the alpha channel could be lost when I render to it, but it might not depending on the implementation.


//Tim

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: