These extensions are referenced by the ratified extensions OES_texture_float and OES_texture_half_float. *Any* implementationsupporting rendering to float or half_float via these extensions (including Chrome) is implicitly enabling WEBGL_color_buffer_float or EXT_color_buffer_half_float respectively.
For the sake of argument let’s say we could change the ratified extensions and remove the references to the extensions you are so hot to reject. Then according to the remaining specifications, implementations should clamp clear colors and fragment shader outputs, making floating-point color buffers virtually useless. Nobody wants to go back to that situation. So these extensions cannot be rejected or returned to draft.
If there truly are technical issues then Ken will have to detail them. I would far rather he concentrate on WebGL 2 than spend time digging into Chrome development history. Since these extensions are based on an existing native extension and are clearly implementable on desktop OpenGL and D3D, I suspect the issues are more to do with them not wanting to spend time making an officlal ANGLE extension equivalent to WEBGL_color_buffer_float rather than anything truly technical. Clearly they have a way to enable the functionality as they are currently doing so implicitly.
I didn’t say that. Did somebody else? I said the possibility was unclear. We can only truly find out by submitting them to the Khronos promoters.
The key word here is “can”. Your revision to the guidelines does not say “will”. If it did, I would have objected as would Jeff.
Description: Message signed with OpenPGP using GPGMail