[Public WebGL] Re: texture_float should imply color_buffer_float

Jeff Gilbert [email protected]
Fri Nov 21 13:17:33 PST 2014

First to clarify, when I say texture_float, I mean both OES_texture_float and OES_texture_half_float. I just didn't want the title to be ridiculously long.

The functionality of WEBGL_color_buffer_float and EXT_color_buffer_half_float is already functionally community approved, since they are invoked in OES_texture_float and OES_texture_half_float respectively. Therefore, we have already de facto promoted them functionality to Community Approved without tests, so let's just make it official, and we can backfill the tests.

I've fine with removing RGB32F, since you can generally just use RGBA32F anyways, and full support for RGB32F is coming in ES3/WebGL2 anyways.
Could you submit a PR for this change?

The goal of WEBGL_color_buffer_float is to deviate from EXT_color_buffer_float such that we can readily implement it in WebGL1, particularly on D3D11, ES2, and ideally D3D9.


----- Original Message -----
From: "Olli Etuaho" <[email protected]>
To: "Florian Bösch" <[email protected]>, "Jeff Gilbert" <[email protected]>
Cc: "public webgl" <[email protected]>
Sent: Friday, November 21, 2014 1:01:31 AM
Subject: RE: [Public WebGL] Re: texture_float should imply color_buffer_float

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?



From: [email protected] <[email protected]> on behalf of Florian Bösch <[email protected]>
Sent: Friday, November 21, 2014 10:22 AM
To: Jeff Gilbert
Cc: webgl, public
Subject: Re: [Public WebGL] Re: texture_float should imply color_buffer_float

readPixels(FLOAT) for a half-float texture would be problematic as the browser would need to convert the bytes he gets back from the GPU to floats one by one up front. Not sure though, do GPUs handle this conversion case? If not, an efficient conversion path could still be provided where the browser performs the conversion on-gpu via RTT half-float -> float.

I'd also like to mention it'd be useful to do readPixels(HALF_FLOAT) and to have a Float16Array data type.

On Fri, Nov 21, 2014 at 4:15 AM, Jeff Gilbert <[email protected]<mailto:[email protected]>> wrote:
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 <[email protected]<mailto:[email protected]>> wrote:
I've filed this bug on my side, including a testcase:

PS: Apparently <ctrl>+enter sends an email in gmail. :)

On Thu, Nov 20, 2014 at 7:11 PM, Jeff Gilbert <[email protected]<mailto:[email protected]>> wrote:
...but at least Firefox and Chrome don't implement it this way.

I've filed this bug on my side, including a testcase:

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list