[Public WebGL] Reject WEBGL_compressed_texture_atc?

Tarek Sherif [email protected]
Sun Aug 20 07:53:13 PDT 2017

Hi all,

I notice that WEBGL_compressed_texture_atc is still listed under "Community
Approved": https://www.khronos.org/registry/webgl/extensions/

Should it not be moved to "Rejected" at this point?

Tarek Sherif

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]>
>> wrote:
>>> I'd like to propose that we reject the WEBGL_compressed_texture_atc
>>> <https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_atc/>
>>>  extension.
>> The extension is in community approved status. The extension process
>> defines that:
>> *A community approved extension can only be rejected in extraordinary
>> circumstances.*
>>> Apparently it was widely supported at the time the extension was created
>>> <https://www.khronos.org/webgl/public-mailing-list/archives/1209/msg00002.php>,
>>> 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
>>> <https://www.khronos.org/registry/OpenGL/extensions/AMD/AMD_compressed_ATC_texture.txt>
>>> 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,
> etc.
> 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
> problem.
> 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
>> situation:
>>    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.
> -Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170820/079d7bf9/attachment.html>

More information about the public_webgl mailing list