[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 12:35, Cedric Vivier wrote:
On Thu, May 20, 2010 at 17:30, Tim Johansson<firstname.lastname@example.org> wrote:Unspecified or incompatible behavior usually comes back to haunt us,
even if we don't think it should matter much. I can think of a few cases
when you might be tempted to do something like that, for example if you
have a grayscale (luminance) image and want to render a red X on top of
it, so I think will give us problems at some point if we don't specify
On 2010-05-20 11:14, Cedric Vivier wrote:
ES section 4.4.7 second paragraph defines conversion takes place.So if you create a texture from an Image object, then bind it to and FBO and
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).
render full RGBA data to it the result will be different depending on the
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.
Good point :)
But is this really an issue ?
I mean, this could happen only if the developer lets the
implementation decide the internalformat of a texture
(0/NONE/DONT_CARE) that he will be using for render-to-texture usage.
It implies the developer does not mind potential loss of information
on the render-to-texture result (meaning here, that the developer does
not need/want alpha).
We could either consider that it is the responsibility of the
developer who performs render-to-texture to make sure the target
texture has been loaded with intended format, or - perhaps - we could
generate an error when attempting to FBO attach a WebGLTexture that
has been loaded with an internalformat of implementation's choosing,
to force this to be explicit. What do you think ?
Like I said above, I don't think we should leave it up to the developers.
The only options left I can think of are either making sure the internal
format is always the same for given image (which could be done by
removing the fallback to RGBA or by always creating RGB(A) textures) or
your suggestion to not allow textures with "automatic" format to be used
as render targets.
It doesn't seem like a big limitation to have to specify the internal
format to use the texture as a render target, it would mean the webgl
implementation has to remember if the texture format was automatically
chosen or not (which is just a flag in the texture object). It might
also be a bit confusing that rendering to some textures doesn't work,
maybe we can solve that with better documentation.
If the gles manpages are correct there is also an issue with
copyTexSubImage2D, it requires the internal format of the texture you
are copying to to be a subset of the internal format of the framebuffer.
If you have an RGB framebuffer it would be possible to copy the data
from that to another RGB texture, but not to a RGBA texture. If the
internal format varies between implementations copyTexSubImage2D could
fail on some browsers which always stores the data as RGBA but not on
others which uses RGB when there is no alpha channel.
The same limitation applies to copyTexImage2D, but since that changes
the internal format it should only matter when the texture with
automatic internal format is bound as a framebuffer. I think that case
would be solved by fixing the binding to framebuffer issue in general.
I'm still a bit worried that there are more potential incompatibilities
we have not thought about yet, so not specifying strictly what format
will be used seems scary to me.
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: