[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



I want these extensions to be implemented, badly. In order to be implemented, they have to be implementable. If they're not implementable, they have no business having made it to community approved. If they cannot be fixed, they're useless. If they're useless, they have no business being in the active registry. Hence, both my proposal to reject them, and my proposal to move them back to draft. It's not too late to correct a mistake. Obstruction to clearing these extensions up one way or another serves no purpose other than compounding that mistake.

On Sat, Feb 7, 2015 at 8:12 PM, Florian Bösch <pyalot@gmail.com> wrote:
These extensions are not ready, neither for community approval, nor for ratification. They cannot be ready, because one vendor, whom we've polled now to render his technical objection has stated that he has objections. Another vendor who purports to champion these extensions, is also not implementing them, for reasons unknown (but also polled).

That a ratified extension refers to these extensions does not provide more credence to them being community ratified, it only serves to compounds the magnitude of error committed.

A situation where extensions are promoted to "community ratified" based on a technicality, resulting in a registry containing extensions vendors are unwilling to implement is not tenable. This constitutes an extraordinary situation.

I'm not eager to reject these extensions. I'm in fact in full recognition of the need for these extensions. But by shoddily pushing them along as has happened, without consensus at any stage, doesn't only harm WebGL and renders the registry a bad joke, it actively prevents these extensions from performing the job they're designed to perform. That is what I'm extremely eager to prevent. And that is why I'm pushing, quite hard, to get this rectified before it becomes a bad example to follow.

On Sat, Feb 7, 2015 at 7:58 PM, Mark Callow <khronos@callow.im> wrote:

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