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

Re: [Public WebGL] WebGL Extensions

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

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;

  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

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.


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