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

Re: [Public WebGL] Reject WEBGL_compressed_texture_atc?



On Thu, Feb 23, 2017 at 5:44 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Thu, Feb 23, 2017 at 11:26 PM, Kai Ninomiya <kainino@google.com> wrote:
I'd like to propose that we reject the WEBGL_compressed_texture_atc extension.
The extension is in community approved status. The extension process defines that:

community approved extension can only be rejected in extraordinary circumstances.
 
Apparently it was widely supported at the time the extension was created, but it looks like now it is no longer available on AMD (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, 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