On Tue, Sep 20, 2011 at 2:26 PM, Chris Marrin <firstname.lastname@example.org>
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 arbitrary reasons.
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 extension.
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.