Re: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float

[Mark Callow <khronos@callow.im>]

On Apr 2, 2015, at 1:02 AM, Florian Bösch <pyalot@gmail.com> wrote:

Are we going to retire unsized format/internalformat parameters from WebGL2? I'd be sorta in favor of this, but it'd present a problem for backwards compatibility. Maybe have a canvas.getContext('webgl2-core') ? It's a deeper question than it appears on the surface. As we're going to progress trough standards, legacy cruft will accumulate (just like it accumulated in the underlying standards), and if we keep it for legacy reasons, we're essentially ending up with a "compatibility profile" where everything hangs around in forever.

That is an interesting idea. I think I’m in favor too. I don’t think it has been discussed at all. Since applications will have to be changed to request a WebGL 2 context instead of a WebGL 1 context, strict compatibility is not essential. I agree we should have a discussion about a process for getting rid of cruft.

 

For WebGL 2 FP color buffer functionality can be exposed with EXT_color_buffer_float and EXT_float_blend. There is no WebGL wrapper yet for the latter. I’ll be happy to draft one, if we are in agreement. Linear filtering of float32 textures can be exposed with OES_texture_float_linear.

I see a possible collision there with WebGL 1 and WebGL 2 extension naming (particularly as these extensions would functionally differ, see unsized vs. sized formats).

Yes. One solution is to make any shared extension document interactions with both WebGL 1 and WebGL 2 in the same way the native OES_texture_float_linear does for  ES 2 and ES 3.

Regards

    -Mark

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail