[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-19 18:00, Cedric Vivier wrote:
On Wed, May 19, 2010 at 17:00, Tim Johansson<firstname.lastname@example.org> wrote:Yes, it needs to be specified better in either case. I just think
specifying that all images are converted to RGB or RGBA depending on if
they have alpha or not is easier to get compatible.
I suspect it might take some time to specify the behavior in a way that does
not introduce incompatibilities, if we are not prepared to take the time to
do so I think it would be better to just stick to what we have.
Actually the helpers we have now neither define which internal format
is used when given DOM element source format is RGB without alpha or
has only two channels (eg. PNG type 4) ... at best the spec somehow
implies that everything is converted (and stored) to RGBA by
I agree, but if the price we have to pay for that memory saving is
incompatibilities I don't think it's worth it.
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).
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.
I do not think there is much incompatibilities issues if we define
conversions according to simple conversion rules directly in relation
with those defined in ES table 3.12 and GL spec table 3.20/23, which
is how the data will be accessed from the shaders (samplers always
return RGBA regardless the internal format used).
The only case I can see where inconsistency could happen is with a
shader accessing G or B components from a texture loaded with NONE
from a L or LA DOM source format and WebGL does a conversion _whereas_
it is running on top of Direct3D : in that case, the default value for
G and B components in the shader will be 1.0 instead of 0 as in OpenGL
(see ARB_texture_rg issue 5 and D3DFORMAT).
If that is considered an important issue, we could define that NONE
should only replace internalformat with RGB or RGBA for now, which is
fine for most usages imho and still automatically provides nice 25%
texture memory savings for many DOM images (some PNGs, all JPEGs).
The first paragraph about converting from CMYK is a bit vague, I guess
it might be OK if we just say all images which are not rgb or rgba must
be converted to rgba if it has an alpha channel otherwise rgb.
Here is a proposal for a section defining conversions performed by
WebGL helpers when loading a DOM element into a WebGLTexture :
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: