[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

Jeff, thanks for the clarification.

If you create patches to ANGLE that enable these extensions to be
exposed on Firefox on Windows, please submit changelists for them.
Also, if you find that the conformance tests for these WebGL
extensions are lacking, please, submit pull requests enhancing the

I support Mozilla's efforts to properly implement these extensions in
Firefox on top of WebGL 1.0, and don't support moving these extensions
to rejected status. Mozilla followed all of the rules when requesting
these extensions be moved from draft to community approved status, and
I think it's both unnecessary and unfair to reject them and require
Mozilla to undo their work.

If it turns out that because of Mozilla's work it's trivial to expose
these extensions in other WebGL implementations, we'll consider doing
so in Chrome.


On Tue, Feb 10, 2015 at 4:01 AM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
> I did some testing, and is seems that WEBGL_color_buffer_float is
> implementable on ANGLE. (I haven't tested EXT_color_buffer_half_float, but
> it seems like it should correspondingly be workable) I didn't test all
> blending combinations, but basic clamped and unclamped tests work fine. The
> only change needed in (Firefox's old copy of) ANGLE is removing the
> call-time clamping on glBlendColor.
> Functionally, removing this seems to work fine, but Shannon (CC'd) would be
> a better person to answer whether this is spec-compliant D3D, or if I'm
> getting lucky with my driver.
> On Mon, Feb 9, 2015 at 12:59 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
>> 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

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl