[Public WebGL] readPixles() can't access float values (OES_texture_float interaction)

Glenn Maynard [email protected]
Mon Sep 19 13:49:38 PDT 2011


On Mon, Sep 19, 2011 at 4:29 PM, Kenneth Russell <[email protected]> wrote:

> The developer has already expressed the intent to use optional
> functionality by enabling the OES_texture_float or
> OES_texture_half_float extension in his or her WebGL application.
>

He's expressed the intent to use the specific optional behavior that the
extension defines.  This is optional behavior *within* that optional
behavior, which creates the original problem all over again.  You can
require it without realizing you're using functionality that itself is
optional--it's a separate testing variable.  You're back at square one.


>  This is correct -- a WebGL implementation would have to try creating a
> floating-point texture and attaching it to an FBO to know whether or
> not to expose a hypothetical "WEBGL_render_texture_float" extension.
>

That's not what I mean.  If it was just that, then I'd agree that it should
be an extension.

The problem I'm referring to is that even if an implementation has support
for FP render targets, it may, for example, not support them with stencil,
or only support them with a depth buffer of a certain resolution.  Just
checking that it supports FP render targets isn't enough to guarantee your
actual renderbuffer will work; you need to check that it works with the
actual configuration you're using.  I don't think this is a problem that can
be fixed with the extension mechanism; it has too many axes.

Doing so isn't technically difficult, but I think that there are
> higher priority issues for WebGL implementors to deal with at this
> point -- for example, finishing the current conformance suite so that
> it is actually possible to ship compliant implementations.
>

If this was to be done at all, then it should be prioritized.  The longer an
incompatible change is delayed, the more work it creates for people.

-- 
Glenn Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110919/6d1aad3e/attachment.html>


More information about the public_webgl mailing list