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

Re: [Public WebGL] WebGL Extensions



On Mon, May 31, 2010 at 2:34 PM, Vladimir Vukicevic
<vladimir@mozilla.com> wrote:
>
> 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).

That would be great from my standpoint.

-Ken

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

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