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

Re: [Public WebGL] WebGL Extensions



Sorry -- I did not mean to imply anywhere that WebGL should ever blidnly expose access to underlying GL extension functionality.  My original phrasing meant that just because a driver supports it, it doesn't mean that it'll be available in WebGL, and that still stands.  For /any/ extension to be available in WebGL, the browser WebGL implementation must fully participate in that and must fully understand the effects of the extension.  There will /never/ be any "automatic" exposure of underlying GL extensions.

getSupportedExtensions() will return the list of strings of available extensions that the implementation knows about.  None of these are enabled by default.  For any of them to be enabled (and their functionality available to the app), getExtension() must be called on it and it must have a non-null return type.  For some extensions, such as float textures, you'll get a non-null object back, but it won't have any properties on it -- but using FLOAT as a token to the texture functions will begin to work.  If the author hadn't called getExtension(), then using FLOAT would have resulted in an error being generated.

    - Vlad

----- "Oliver Hunt" <oliver@apple.com> wrote:

> On Jun 3, 2010, at 9:24 AM, Gregg Tavares 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.
> 
> 
> How does the runtime _know_ that an extension is only exposing an new
> enum? How would the glsl validator _know_ what glsl features existed
> due to an arbitrary extension? The implementation needs to handle
> every extension itself -- it can't do it automatically through the
> glGetExtensions API (or whatever it's called)
> 
> 
> --Oliver
-----------------------------------------------------------
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: