[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Extension mechanism for WebGL
- To: Chris Marrin <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] Extension mechanism for WebGL
- From: Kenneth Russell <email@example.com>
- Date: Thu, 11 Feb 2010 17:36:19 -0800
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265938585; bh=qZywT58nedu+BFfd7Wwlnq3kLG8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=R+MonGihugLMrhpQfsnV6NiHxP6OwKGpKqOKKaS5VxiPbA/K0q17seZOG/t7dK3E3 nzhegjYgyIRLFcV4pE4Qw==
- Domainkey-signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=QZisXe7EdwyxVP8xDPUFNVZR+Qr8VWwlFW13YC3y+kzFeTdWN4a223Effi9xmd3x2 Jk1ANWu9Eij3Gj8EB7svQ==
- In-reply-to: <9BCC191D-D2C1-46AC-96F0-B159A6C6F59E@apple.com>
- References: <9BCC191D-D2C1-46AC-96F0-B159A6C6F59E@apple.com>
- Sender: email@example.com
On Thu, Feb 11, 2010 at 4:47 PM, Chris Marrin <firstname.lastname@example.org> wrote:
> We decided at the F2F to add an extension mechanism. Even though we don't plan on having any extensions included in the first release it was believed that it will give browser vendors a standard way to add extensions as needed.
> There are a few illustrative examples of existing OpenGL ES 2.0 extensions. One is OES_texture_float (http://www.khronos.org/registry/gles/extensions/OES/OES_texture_float.txt). This extension provides no new function calls and no new enums. It simply allows data of type FLOAT to be passed to texImage2D. Another is OES_point_sprite (http://www.khronos.org/registry/gles/extensions/OES/OES_point_sprite.txt), which adds no new functions, but has a couple of new enums. The last is OES_texture_3D (http://www.khronos.org/registry/gles/extensions/OES/OES_texture_3D.txt), which has both new functions and enums.
> There are 3 steps to using an extension: discovery, enabling and access. There are a few ways to do discovery:
> - Provide a call to return a list of all supported extensions.
> - Provide a call that returns true or false given an extension string.
> - Provide no way to do discovery, simply fail when an attempt is made to access the extension.
> We've decided that we want to disallow the use of an extension unless it is enabled. So an enable API is needed. This could be explicit (enableExtension(name)) or implicit in the attempt to access the extension.
> The last step is access. There are a couple of choices here as well:
> 1) Have the enums and API calls part of the returned context, using the OpenGL mechanism of adding a suffix to them to disambiguate the namespace. So, for instance:
> var context.haveTex3D = context.enableExtension("OES_texture_3D")
> if (context.haveTex3D)
> context.texSubImage3DOES(context.TEXTURE_3D_OES, ...);
> , context.TEXTURE_3D_OES would be an enum name and context.texSubImage3DOES() would be a function call. The function call would throw if an attempt is made to use it without first calling an enableExtension(name) method.
> 2) Add a getExtension(name) method and have it return a new object which would contain any enums or API calls in the extension. For instance:
> context.tex3D = context.getExtension("OES_texture_3D");
> if (context.tex3D)
> context.tex3D.texSubImage3D(context.tex3D.TEXTURE_3D, ...);
> Both of these options assume that enabling and detecting the presence of an extension are included in the call (enableExtension in the first case, getExtension in the second). We could still provide an explicit hasExtension(name) or getExtensionList() call. But I don't think it adds any value.
> I prefer choice (2) because:
> a) It allows us to express each extension as a standalone WebIDL interface rather than snippets to be added to the context.
> b) It uses the object oriented mechanisms at our disposal for disambiguation of names rather than "C style" name mangling.
> c) It avoids the problem of "undocumented" property pollution of the WebGLRenderingContext. What if the user places a property on the context object. They have chosen a property name that is not in the WebGL spec, so it seems safe. But if that name clashes with a name used by an extension then behavior will be different depending on whether or not an implementation has that extension and how it is implemented.
> Other comments?
I prefer choice (2) as well for all of the reasons you mention above.
I believe it would also work better if a WebGL binding to a statically
typed language such as Java is ever created. In such an environment it
is undesirable to have methods disappear on a class such as
WebGLRenderingContext, which would occur if a user's newer code were
run on an older browser that doesn't yet declare a particular
extension's entry points.
You are currently subscribe to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: