[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float




On Feb 6, 2015, at 11:29 PM, Florian Bösch <pyalot@gmail.com> wrote:

I believe it's established that consensus on rejection cannot be reached. Therefore I've started the alterntive proposal of moving these extensions back to draft: https://www.khronos.org/webgl/public-mailing-list/archives/1502/msg00042.html

The proposal to rejection is suspended until the alternate proposal is resolved. A failure to find a satisfactory resolution to these extensions will circle back to this rejection proposal.


These extensions are referenced by the ratified extensions OES_texture_float and OES_texture_half_float. *Any* implementation 
supporting 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.

  • These extensions cannot be ratified,
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.
  • which is a stated reason that they can be rejected in the extension development process guidelines. If you object to this reason, please move your objection over to the extension development process.
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.

Regards

    -Mark


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