[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<firstname.lastname@example.org> wrote: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 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
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
(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 copyTexSubImage2D we do need to make sure the target texture does
not have internal format 0/NONE/DONT_CARE as it uses the existing
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.
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.
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
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?
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: