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

[Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float

It's important to realize that it's only Mozilla who explicitly exposes the extension. At least Chrome (and I believe others) implicitly support the extension, otherwise they cannot support rendering into floating-point FBs.

This is the text from OES_texture_float:
"Implementations supporting float rendering via this extension will implicitly enable the WEBGL_color_buffer_float extension and follow its requirements."

Technically speaking, a spec-compliant implementation cannot expose OES_texture_float, allow render-to-RGBA32F, and not support the WEBGL_color_buffer_float extension. That is, Chrome (for instance) already implicitly claims support for all the restrictions of WEBGL_color_buffer_float if they support OES_texture_float and allow render-to-RGBA32F.

As the spec stands today, Chrome is either out-of-spec in its implicit support of WEBGL_color_buffer_float as invoked by OES_texture_float, or WEBGL_color_buffer_float can be exposed today with no technical issues.

To be clear, as the specs stand today, WebGL implementations may either:
* Allow render-to-float32 when WEBGL_color_buffer_float is explicitly activated
* Allow render-to-float32 when WEBGL_color_buffer_float is implicitly activated by OES_texture_float
* Not allow render-to-float32.

That is spec-as-written today.

WEBGL_color_buffer_float is alive and well, but many implementations are not explicitly claiming support for it. If we reject these extensions, by spec, we'll need to stop allowing render-to-float, or get new extensions.

I posit that we don't actually need new extensions, unless there's a technical reason that puts us all out-of-spec in our support for WEBGL_color_buffer_float, whether explicit or implicit. If there is a technical reason for this, we should rewrite the extension(s) until it's technically and spec-wise feasible to support render-to-float.

On Fri, Feb 6, 2015 at 2:15 PM, Dean Jackson <dino@apple.com> wrote:

On 7 Feb 2015, at 8:32 am, Florian Bösch <pyalot@gmail.com> wrote:

Look at it like this:

These extensions will never solve the problem they're designed to solve. They will not solve it because they're largely unimplementable (as is evidenced by the refusal of at least one vendor to implement them on technical grounds, and by the low activation rate of another vendor). These extensions should not have moved beyond the proposal and draft stages because clearly consensus on them was not reached, and technical issues where not addressed. But because they're now in community approved status, they cannot be reworked to make them adequate tools to solve the problem. And because they're in the registry, no other extension can be introduced that would actually address the same problem.

I'm very unhappy about limbo extensions like this. I think they're bad form, and they're bad for WebGL as a whole.

I don't feel as strongly as Florian, but if Mozilla is the only implementor that plans to support them, then I don't see how these could be considered community approved. Mozilla can continue to support them proprietarily.


On Fri, Feb 6, 2015 at 10:12 PM, Florian Bösch <pyalot@gmail.com> wrote:
Like I say that's another thread if it's ok to have perpetual community approved extensions only implemented by a single vendor.

I will note though that even the one vendor who does "implement" it, only exposes it to 2% of its install base. I'm definitely not happy with a single vendor low single digit extension eating up space in the registry providing the illusion of a functionality being "addressed", when in fact, it isn't.

On Fri, Feb 6, 2015 at 9:59 PM, Kenneth Russell <kbr@google.com> wrote:
On Fri, Feb 6, 2015 at 11:41 AM, Florian Bösch <pyalot@gmail.com> wrote:
> On Fri, Feb 6, 2015 at 8:35 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
>> The WG should not categorically reject extensions which it is merely
>> unwilling to ratify. If it's community approved, I fail to see why it needs
>> to either be ratified or rejected.
> That's a debate for another thread on extension development policy. Assuming
> these two working facts:
> Every extension should be ratified
> These extensions cannot be ratified because implementations from other
> vendors will not emerge.
> Do you wish to add anything to this observation to justify the objection to
> the rejection other than "we already implemented it"?
> Circling back for a second to the community approved status of these
> extensions, they're community approved on a technicality because
> OES_texture_float references them, and if they would be in draft, that would
> make it awkward to support them. Technical difficulties in implementation
> where noted by Kenneth Russel long before they where moved to community
> approved, and it's my opinion that they shouldn't have been moved to
> community approved while technical difficulties aren't resolved.

I don't want to fuel a long debate on this topic but since Mozilla
pressed to move these extensions out of draft because they felt they
were implementable, I prefer to leave them indeterminately in the
community approved state.