[Public WebGL] Reject WEBGL_compressed_texture_atc?
Sun Aug 20 07:53:13 PDT 2017
I notice that WEBGL_compressed_texture_atc is still listed under "Community
Should it not be moved to "Rejected" at this point?
On Thu, Feb 23, 2017 at 10:02 PM, Kenneth Russell <[email protected]> wrote:
> On Thu, Feb 23, 2017 at 5:44 PM, Florian Bösch <[email protected]> wrote:
>> On Thu, Feb 23, 2017 at 11:26 PM, Kai Ninomiya <[email protected]>
>>> I'd like to propose that we reject the WEBGL_compressed_texture_atc
>> The extension is in community approved status. The extension process
>> defines that:
>> *A community approved extension can only be rejected in extraordinary
>>> Apparently it was widely supported at the time the extension was created
>>> but it looks like now it is no longer available on AMD
>>> <http://feedback.wildfiregames.com/report/opengl/feature/GL_AMD_compressed_ATC_texture> (according
>>> to the OpenGL capabilities database & on my own machine) making it only
>>> possible to implement on Qualcomm devices. Since there are other, newer
>>> compressed texture formats available on Qualcomm, this extension seems
>>> pretty useless.
>>> The AMD_compressed_ATC_texture spec
>>> is very old and underspecified. This is creating quite a bit of maintenance
>>> work for the conformance tests and browsers - the tests fail currently on
>>> Qualcomm (the only platform where they're available), despite Qualcomm
>>> seeming to conform to the underspecified spec.
>>> Are there any objections to rejecting this extension?
>> I'll summarize the circumstances for the reason for rejection thus:
>> 1. Only marginally supported by hardware
>> 2. Badly specified upstream
>> 3. Unreliable when actually used
>> Do these conditions meet the criteria of "extraordinary circumstances"?
>> If so, how can we avoid promoting extensions to community approved in the
>> future that would befall the same fate?
> In my opinion, the current situation does meet this criterion.
> The difficulty with this extension is that support for it has dwindled.
> The underlying extension is ambiguous with respect to important
> constraints, like whether texture sub-updates must occur on block
> boundaries, and errors generated in boundary cases.
> The associated conformance tests are failing on the only device we have
> which claims support for the format, so we can't validate against a second
> implementation to know whether these are bugs in the driver, test, browser,
> We could simply stop claiming support for this extension in our browser,
> but that's not helpful to the community, because the next browser that
> attempts to reach conformance on similar devices will run into the same
> It's for this reason that I am proposing rejecting this extension at this
> late date. It's the only way that we can remove the problematic, and likely
> buggy, conformance test.
> Going forward, we should ensure that extensions have robust multi-platform
> support, and that the conformance tests have been verified to pass on
> multiple platforms, before moving them to community approved.
> A brief history of this extension:
>> - Introduced by Benoit Jacob in 2012 as draft (back then the proposal
>> status didn't exist). A poll for objections on the ML didn't net any
>> response or objection so after 3 days it was put into draft status.
>> - No discussion of atc happened at all for 2 years, support status
>> remains marginal.
>> - Proposed to move to community approved by Kenneth Russel in 2014 it
>> got swept up in an effort to promote several draft extensions prior to iOS
>> gaining WebGL support. Jeff Gilbert, Brandon Jones and Dean Jackson replied
>> to the poll in favor to community approve, and one day later Kenneth moved
>> these extensions (including atc) to community approved.
>> - No discussion of atc happened at all for the next 3 years (which
>> brings us to today)
>> I believe that a pattern is discernible here:
>> 1. No rigorous discussion seems to occur on the extension
>> 2. Moving from one status to another is quickly enacted after only
>> brief polling periods
>> 3. Participants in what little communication there is are not diverse
>> (only seem to include UA vendors)
>> 4. Years after its introduction the extension is largely unsupported
>> 5. The extension gets lumped together with others instead of getting
>> the attention it should have gotten.
>> From this I believe we can formulate a guideline on how to avoid this
>> 1. If an extension isn't announced on the ML or isn't discussed at
>> all, then the quality of any poll for consent is suspect.
>> 2. It should only move to a new status after a grace period that
>> should be somewhat longer than a few days (maybe a month or two?)
>> 3. It would be preferable if input from multiple constituents is
>> present, and if that is lacking, calls should be made to those constituents
>> to render an opinion.
>> 4. If an extension lingers with barely any support, it might indicate
>> trouble and should be investigated.
>> 5. An extension status change should not be lumped together with
>> others, for it could obscure issues in the status change.
>> I apologize that I and we have rushed these extensions in the past. We'll
> try to do a better job going forward of giving things sufficient bake time
> in the community.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl