I don't think we should move the extension forward before there's conformance
tests for all of the new behavior (creating renderbuffers and querying framebuffer attachment type for example), preferrably in its own test file. The test should also test the behavior when only WEBGL_color_buffer_float is enabled and OES_texture_float is
not. Also, there are a few other things I'd like to point out:
One issue with the extension is that rendering to RGB32F is not natively supported on either OpenGL ES or DirectX. Of course RGB could be emulated with RGBA (as I believe some browsers have opted to implement this on DirectX), but I think it's better for app developers if less tricks are played behind the scenes, so they don't get the mistaken idea that RGB32F would be in any way more efficient than RGBA32F. So I'd prefer if RGB32F support was made optional in this extension before it moves forward. This would also prepare people for https://www.khronos.org/registry/webgl/extensions/EXT_color_buffer_float/ , the extension that will take over in WebGL 2, which doesn't include RGB32F at all.
Also, I assume that the move to community approved would have to apply to EXT_color_buffer_half_float as well, since WEBGL_color_buffer_float refers to that in its specification?
In particular, it looks like if texture_float implicitly enables RTT with float textures, it should also enable renderbufferStorage with RGB[A]32F, and readPixels(FLOAT).Chrome apparently supports readPixels(FLOAT) for texture_float, but not readPixels(FLOAT) for texture_half_float. Firefox does not currently allow either under implicit activation.
On Thu, Nov 20, 2014 at 7:12 PM, Jeff Gilbert <firstname.lastname@example.org> wrote:
I've filed this bug on my side, including a testcase:PS: Apparently <ctrl>+enter sends an email in gmail. :)