[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Adding internalformat param to all texImage2d variants
On Thu, May 20, 2010 at 22:24, Tim Johansson <firstname.lastname@example.org> 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
> 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)
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: