[Public WebGL] readPixles() can't access float values (OES_texture_float interaction)
Tue Sep 20 12:15:31 PDT 2011
On Tue, Sep 20, 2011 at 2:26 PM, Chris Marrin <[email protected]> wrote:
> I meant that there's no precedence in WebGL. Remember our extension
> mechanism differs from that of OpenGL. In WebGL you need to enable an
> extension to use it's feature(s). We should stick with that.
I agree that this is useful in general, to make testing variables explicit,
and help ensure you're not depending on a feature without realizing it's
optional. But I'm not sure it would do that here, because the
implementation can still treat the renderbuffer as "incomplete" for
For example, you know that if OES_texture_float loads successfuly,
floating-point textures (not framebuffers) are available. Barring bugs, or
exceptions to the rule (MAX_TEXTURE_SIZE and other non-extensioned
variables), any code you write using floating-point textures will work on
any system that exposes OES_texture_float. There are only two states:
systems with the extension and systems without; and you can test that your
code works in both states simply by importing or not importing the
That doesn't work with renderbuffers. Even if a system supports
floating-point framebuffer attachments, the RB configurations which are
actually framebuffer complete can vary. The end result is that you still
have to test every hardware and driver combination (in theory) to be sure
your code works. Having a separate extension doesn't seem very helpful if
it doesn't solve that problem.
If there's a feature not supported by GLES, we should require an extension
> to enable it.
There still is an extension required--it's still part of OES_texture_float.
It just doesn't split apart support for floating-point textures and
floating-point framebuffer attachments. Both should always fail if that
extension isn't enabled.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl