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

Re: [Public WebGL] WebGL Extensions



Your pseudocode is roughly how I recollect things will work; we need to get this written up in the spec (Chris, others -- I can take a stab at this if you guys want).

The important thing to remember is that any extensions must be implemented by the browser itself, regardless of what the underlying hardware supports -- that is, there's no way from the content JS side to get access to, say, ARB_occlusion_query unless the browser itself implements the extension.  So it needs to be supported in two places: the underlying GL implementation and the browser WebGL implementation before it can be used by content script.

    - Vlad

----- "Ilmari Heikkinen" <ilmari.heikkinen@gmail.com> wrote:

> 2010/5/31 Andor Salga <asalga@learn.senecac.on.ca>:
> > Ok, thanks.
> >
> > Can you guys point me to some resources for writing WebGL
> extensions? How
> > would someone go about writing one? I need to start working on it
> since I
> > have a project which will require GL_ARB_occlusion_query. Having
> the
> > extension done by the time WebGL extensions are supported would be
> really
> > great.
> >
> > Thanks,
> > Â Andor
> 
> As far as I know there is no consensus on how the extension mechanism
> would work. So you're pretty much pioneering on here. I'd start by
> writing a JavaScript object that wraps all your extension-requiring
> WebGL calls. Then brush up your C++ and go hack the WebGL
> implementation in some browser to add a new native object type for
> your extension (which would implement only the stuff the extension
> does and call the underlying webgl context) ... tell you what, this
> is
> getting complex.
> 
> Hmm. The WebGL context needs to reject invalid calls. And the
> extension calls are invalid calls unless the extension is enabled.
> The
> problem is how to enable the extension and expose the extension
> constants and methods.
> 
> The desktop GL enables extensions by never disabling them. It knows
> what extensions it supports and if you're trying to do something it
> doesn't support, it errors. The constants are exposed in the header
> files and the entrypoints hot-plugged in by extension managers like
> GLEW.
> 
> The current WebGL implementations are light-weight wrappers on top of
> desktop GL with error checking and validation, plus an IDL file to
> define all the methods and constants in the context. You can't really
> add stuff to the IDL at run-time (I .. think?) So you'd have to
> either
> put all the extension constants in the WebGLContext IDL or define
> some
> kind of extension object with the constants and methods.
> 
> A hypothetical GL_ARB_occlusion_query extension object might look
> something like this:
> 
> // FIXME implement
> WebGLARBOcclusionQueryExtension {
>   int SAMPLES_PASSED = 0x8914;
>   int QUERY_COUNTER_BITS = 0x8864;
>   int CURRENT_QUERY = 0x8865;
>   int QUERY_RESULT = 0x8866;
>   int QUERY_RESULT_AVAILABLE = 0x8867;
> 
>   uint genQuery();
>   void deleteQuery(uint id);
>   boolean isQuery(uint id);
>   void beginQuery(enum target, uint id);
>   void endQuery(enum target);
>   int[] getQuery(enum target, enum pname);
>   int[] getQueryObject(uint id, enum pname);
> }
> 
> And you'd get a version bound to the issuing WebGLContext by doing
> something like
> 
> // FIXME implement
> var occ = glctx.getExtension("GL_ARB_occlusion_query");
> if (occ) { // great, found it
>   var query = occ.genQuery(); // internally makes the glctx context
> active and calls genQueriesARB (guess you need to find-and-bind those
> as well)
>   // do stuff
>   occ.deleteQuery(query);
> }
> 
> Disclaimer: this is all my pseudocode sketching and likely not how it
> would turn out in the end.
> 
> But hey, try doing a prototype and come back with stories of great
> glory and a treasure chest full of implementation tidbits.
> 
> Cheers,
> Ilmari
> 
> >
> > ----- Original Message -----
> > From: Chris Marrin <cmarrin@apple.com>
> > Date: Monday, May 31, 2010 12:54 pm
> > Subject: Re: [Public WebGL] WebGL Extensions
> > To: Cedric Vivier <cedricv@neonux.com>
> > Cc: Andor Salga <asalga@learn.senecac.on.ca>, public webgl
> > <public_webgl@khronos.org>
> >
> >>
> >> On May 30, 2010, at 11:13 AM, Cedric Vivier wrote:
> >>
> >> > On Mon, May 31, 2010 at 01:34, Chris Marrin
> >> <cmarrin@apple.com> wrote:
> >> >> I'm asking because I'm interested in using
> >> GL_ARB_occlusion_query.>>>
> >> >>> I first thought the Quake 2 demo was using extensions:
> >> >>> http://playwebgl.com:8080/GwtQuake.html
> >> >>>
> >> >>> But then I realized it was probably just listing ones
> >> available. Can anyone give me some thoughts on this?
> >> >>
> >> >> There will be no extensions available in WebGL in the first
> >> release.>
> >> >
> >> > Chris, has something been decided in F2F with regards to the
> strings
> >> > returned by getString(GL_EXTENSIONS) and similar calls ?
> >> > (iirc this issue was present in the agenda)
> >>
> >> I don't have my notes with me. I have wanted to post them, but
> >> I've been out sick for the last few days. My recollection is
> >> that we won't ever return anything in the GL_EXTENSIONS string.
> >> We may even have removed it, I don't remember. We will return an
> >> array of strings in getSupportedExtensions() instead.
> >>
> >> >
> >> > Currently WebKit returns the list of native GL extensions,
> >> which might
> >> > be confusing to web developers who might then assume that they
> could
> >> > be used in WebGL as well without a WebGL version of the
> extension
> >> > specification (as it seems was implied by Andor's question wrt
> >> > ARB_occlusion_query).
> >>
> >> Yes, that's a bug
> >>
> >> -----
> >> ~Chris
> >> cmarrin@apple.com
> >>
> >>
> >>
> >>
> 
> -----------------------------------------------------------
> 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: