[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



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.

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.