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

Re: [Public WebGL] extension registry markup/split for webgl 1, 2 or both

I don't mean to split the actual extension. I mean to split (or at least mark up) the pages indexing the extensions.

If you want to present a clean picture for instance, you should filter the landing page for extensions which are <api version="2.0">. But people will still be interested in extensions which are <api version="1.0"> and which are not <core version="2.0"> because they still have to support these profiles. On the other hand, people will also be interested about extensions which are only <core version="2.0"> because it gives them a good overview about which extensions they should bother about to provide backwards compatible applications.

I see these meaningful changes that could be made:
I'd default the filter to extensions which are <api version="2.0"> because that gives the cleanest picture for newcomers.

On Thu, Apr 2, 2015 at 4:19 AM, Kenneth Russell <kbr@google.com> wrote:
On Fri, Mar 27, 2015 at 3:30 AM, Florian Bösch <pyalot@gmail.com> wrote:
> Ticket: https://github.com/KhronosGroup/WebGL/issues/917
> It's currently the case that some purely WebGL 1 related extensions are
> exposed on WebGL 2 contexts which shouldn't be (because they're WebGL 2
> core). It's also the case that it's not clear in the extension registry
> overview, which extensions are WebGL 1, 2 or both.
> The extension definitions have the ability to mark up against which
> specification they're written, and they can also specify in which version
> they become core (example quoted from EXT_frag_depth below)
> <depends>
>   <api version="1.0"/>
>   <core version="2.0">
>     <glsl version="300 es"/>
>   </core>
> </depends>
> Would it make sense to mark up/divide the extension in the overview in some
> fashion?

I think that this will make the extension registry more complicated to
navigate. It will add three new sections: extensions applying to WebGL
1.0, 2.0, and both. It also won't scale well to future releases. Since
the intent is to have fewer rather than more extensions, I think the
current extension registry organization is reasonable.