[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



Here's the deal with the Firefox numbers:

Currently, Release is 35, Beta is 36, and Nightly is 38.[1]

In Firefox 33, we landed a fix[2] which moves the color_buffer extensions behind a draft extensions pref, because they were still in Draft status at the time. 33 became Beta on 2014-09-02, and then Release on 2014-10-14. Looking at the data for Firefox+OSX, you can see a large activation rate for WEBGL_color_buffer_float declines sharply in October and November 2014, in line with this fix hitting the Release channel.

In Firefox 36, we landed a fix[3] which moves the color_buffer extensions out from behind Draft, as they were promoted to Community Approved. In addition, we landed another fix[4] which enables WEBGL_color_buffer_float support on ANGLE. (I am currently working on a patch to support EXT_color_buffer_half_float on ANGLE) This means that you will see near-zero activation for this extension on Windows before 36. 36 is on Beta right now, and it will move to Release on 2015-02-24. The data for Firefox+OSX+WEBGL_color_buffer_float appears to be showing a small uptick already, but it's likely within the noise floor. However, you can definitely see Firefox+Windows activation for WEBGL_color_buffer_float coming on line, though it's still sitting at 2%.

If it's possible to isolate Firefox 36+ from your data, how does the activation rate look there?

I'm going to do my own investigation on the correctness of our implementation in the mean time, to be sure we're exposing it properly.

[1]: https://wiki.mozilla.org/RapidRelease/Calendar
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1023553
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1105535
[4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1102667

On Sat, Feb 7, 2015 at 11:23 AM, Florian Bösch <pyalot@gmail.com> wrote:
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