[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 understood that you meant to modify the landing page, but still
think that it will introduce complexity in the overview. It isn't the
right time to default the extensions landing page to display by
default only those extensions applying to WebGL 2.0 because initial
prototypes are only just becoming available. Once they're more broadly
available it'll be a better time to reconsider.

-Ken


On Wed, Apr 1, 2015 at 11:53 PM, Florian Bösch <pyalot@gmail.com> wrote:
> 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:
>
> Add "tags" to the extension overview derived from their <depends>
> specification so you can get a view at a glance what they are.
> Add a filtering widget (checkboxes, what have you) that blends out those
> extensions which you've filtered out
>
> 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.
>>
>> -Ken
>
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------