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

Re: [Public WebGL] WebGL Extensions



On Thu, Jun 3, 2010 at 9:24 AM, Gregg Tavares <gman@google.com> wrote:
>
>
> On Thu, Jun 3, 2010 at 5:12 AM, Oliver Hunt <oliver@apple.com> wrote:
>>
>> On Jun 3, 2010, at 4:47 AM, Steve Baker wrote:
>>
>> > Vladimir Vukicevic wrote:
>> >> Hm, I thought we didn't have this which is where the confusion came
>> >> from, but looks like Chris put it in a while ago:
>> >>
>> >>
>> >> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html#5.14.14
>> >>
>> >> Maybe it's just missing a sentence or two at the end explaining that
>> >> extensions are WebGL specific, and if WebGL is built on top of an underlying
>> >> OpenGL driver, that driver's extensions will not necessarily be exposed?
>> >>
>> > IMHO, it is essential that WebGL does NOT expose underlying driver
>> > extensions by default.  The reason being one of security.
>>
>> For what it's worth the way that the JS/DOM bindings work in most (all?)
>> browsers require every exposed function to be defined and implemented
>> explicitly -- it would not be possible for an implementation to automate the
>> exposure of an arbitrary set of unknown extensions.
>
> Plenty of extensions only enable new ENUMs and new features to GLSL. No
> changes to the API are required so it's very possible to automate the
> exposure of an arbitrary set of unknown extensions unless WebGL specifically
> prevents that exposure.

Agreed.

Because these extensions will generally be the actual underlying
OpenGL ES 2.0 compatible extensions, just exposed and enabled
differently for WebGL, I don't think it's warranted to state that
extensions are WebGL specific. Concrete examples in the spec would
definitely help though -- perhaps one like OES_texture_float where no
new enums or functions are defined, just new functionality that needs
to be enabled, as well as one which adds both functions and enums,
like OES_texture_3D.

-Ken

>>
>> --Oliver
>>
>> >
>> >  -- Steve
>> >
>> > -----------------------------------------------------------
>> > 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:
>> >
>>
>>
>> -----------------------------------------------------------
>> 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:
>>
>
>

-----------------------------------------------------------
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: