[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 21:32, Tim Johansson <timj@opera.com> wrote:
> 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.

Yeah, WebGL currently has a similar imposed limitation which forces an
implementation to remember on which target a buffer has been bound for
the first time (afterwards the buffer cannot be bound to another
target by section).
Documentation wise, moreover short line about that in the spec, when
an error is synthesized implementations could post a message reminding
this to the JS console or whatever debugging/logging mechanism

> 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.

Yeah fixing framebuffer attachment issue as above would also solve this afaic.

> 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.

Yes we should think carefully and heavily test that there is no other
potential incompatibility, if we cannot guarantee this I agree we
better strictly define which format is used (table XXX.Z without RGBA
as potential fallback) or scrap automatic conversion unfortunately.

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: