[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 17:02, Cedric Vivier wrote:
On Thu, May 20, 2010 at 22:24, Tim Johansson<timj@opera.com> wrote:
For copyTexImage2D I think so too, but it would not fix copyTexSubImage2D as
copyTexSubImage2D can fail in some cases if the _target texture_ has too
'high' color format such as RGBA instead of RGB when copying from an RGB
framebuffer.

If you create an FBO with a color attachment which is specified by the
author to be RGB and then try to copy data from that to a texture which has
'automatic' format it will fail if the browser set the format of that
texture to RGBA but not if it set it to RGB. In this case the texture with
'automatic' format is not used as a render target, the render target has a
well specified format (RGB), so fixing the framebuffer attachment issue
would not fix it.

I'm not sure I get what you mean by this that is not fixed the same way on copyTexSubImage2D as done with the limitation on copyTexImage2D since both copyTex* calls have the limitation above. The limitation ensures that both framebuffer render texture and target texture of a copyTex(Sub)Image2D have been loaded with a specific format. (just to be thorough, copyTexImage2D's internalformat cannot be 0/NONE/DONT_CARE, as discussed earlier this would be a feature only available to DOM helpers)

For copyTexImage2D only disallowing 'automatic' internal format on the framebuffer is enough since copyTexImage2D will not use the internal format of the bound target texture, it sets a new one. So in this case the internal format of the bound target texture is irrelevant and does not need to be checked.

For copyTexSubImage2D we do need to make sure the target texture does not have internal format 0/NONE/DONT_CARE as it uses the existing internal format.

Raising an error if the target texture does not have a specified internal format fixes the issue, but I don't see any reason to do so for copyTexImage2D, only for copyTexSubImage2D.

In 6.2 :

"""
A call to framebufferTexture2D with a texture which has been loaded
with 0/NONE/DONT_CARE internalformat will generate an
INVALID_OPERATION error and leave the framebuffer's attachments
untouched.
Additionally, a call to copyTexImage2D or copyTexSubImage2D when
currently bound texture has been loaded with 0/NONE/DONT_CARE
internalformat will generate an INVALID_OPERATION error and leave the
target texture untouched.
"""

How would that sound?

That would fix the issue, but I don't think there is a need to limit calls to copyTexImage2D as stated above, only limiting copyTexSubImage2D should be enough.

//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: