Platform/GFX/WebGL/Contribute/Extensions

From MozillaWiki
< Platform‎ | GFX‎ | WebGL
Jump to: navigation, search

Here is a Bugzilla search returning open WebGL extension implementation 'bugs' i.e. extensions that need implementing.

Implementable WebGL extension specifications are found at the Khronos WebGL Extension Registry.

General Approach

For the purposes of this page, we will pretend there is a WebGL extension named WEBGL_foo_bar that we're trying to implement. This extension will be listed in the WebGL Extension Registry, which will link to the specification of this extension. Here's an example of an extension specification.

Adding the Web IDL

Files to be modified in this section:

WebIDL stands for "Web interface definition language". It's how Web APIs are specified. The extension spec should provide a snippet of WebIDL. In most cases, it can be used as-is or with very little modification in Mozilla's IDL system.

Add the Web IDL from the extension spec to mozilla-central/dom/webidl/WebGLRenderingContext.webidl. For the interface name, instead of the one given in the extension spec, try to choose a name more in line with existing interface names here. For example, for WEBGL_foo_bar, you could choose WebGLExtensionFooBar. Do not use any prefix (like MOZ_ or EXT_). Prefixes are only wanted in the extension string (see below). Here like in other places where all WebGL extensions are listed, please preserve alphabetic order. On the line just before your interface declaration, make sure that you have [NoInterfaceObject]. The IDL that you add should look like this:

[NoInterfaceObject]
interface WebGLExtensionFooBar
{
  // maybe something here
};

Add an entry about your new interface to mozilla-central/dom/bindings/Bindings.conf. Check existing WebGLExtension* entries for examples. You should have something like:

'WebGLExtensionFooBar': {
   'nativeType': 'mozilla::WebGLExtensionFooBar',
   'headerFile': 'WebGLExtensions.h'
},

If you need more information, consult WebIDL bindings or ask for help on IRC in channel #content

The Extension Class

File to be created in this section:

Files to be modified in this section:

Edit mozilla-central/content/canvas/src/WebGLExtensions.h and define the WebGLExtensionFooBar class, similar to what's being done for WebGLExtensionStandardDerivatives.

Create a new implementation file for your extension, say mozilla-central/content/canvas/src/WebGLExtensionFooBar.cpp, mimicking existing extension implementation files such as mozilla-central/content/canvas/src/WebGLExtensionStandardDerivatives.cpp. Add it to the list of source files in mozilla-central/content/canvas/src/Makefile.in.

This C++ class won't automatically be aware of what you've put in the IDL. If the IDL interface for this extension has methods or attributes (the majority are empty or only have constants, which don't require any C++ work), you will need to manually declare and implement the corresponding C++ methods here. See WebGLExtensionLoseContext for an example. For general documentation about that, refer to WebIDL bindings.

Exposing the Extension

Files to be modified in this section:

These files may also have to be modified:

In this section, we do the work to actually expose this extension, in WebGL getExtension and getSupportedExtensions methods. The file to edit is mozilla-central/content/canvas/src/WebGLContext.cpp. This is where you expose the extension, possibly with a MOZ_ prefix.

The rule to determine whether to use a MOZ_ prefix is very simple: if the WebGL extension is a "Draft" (that's written in the spec, and in the extension registry) then you must expose it with a MOZ_ prefix. If it is not a "Draft", then you must not expose it with a MOZ_ prefix.

You will also need to add an enum value in WebGLExtensionID in mozilla-central/content/canvas/src/WebGLContext.h.

The functions exposed to scripts are WebGLContext::GetExtension and WebGLContext::GetSupportedExtensions. They call another internal function that you'll have to edit as well: WebGLContext::IsExtensionSupported. That's where you'll have to decide whether this extension is supported or not by the client. If you have to query the GL_EXTENSIONS string of the underlying OpenGL context, call gl->IsExtensionSupported(enum value). Indeed, we are checking for a list of extensions when we create a OpenGL context, so that subsequent checking for them is really fast. If the OpenGL extensions you need to check for haven't yet been added to the list that we check for, you'll have to edit these files in a straightforward way (search for IsExtensionSupported):

Implementing the Extension

Files that may typically have to be modified in this section (this depends on the extension):

Finally, let's implement what this extension actually does. The spec describes that.

If the extension modifies the behavior of one of the standard WebGL context methods, you will probably have to modify mozilla-central/content/canvas/src/WebGLContextGL.cpp as that is where these methods are implemented. You might also need to make some more edits to mozilla-central/content/canvas/src/WebGLContextGLValidate.cpp, or to other files in this directory, or to gfx/gl/GLContext.*.

Sometimes, while implementing a WebGL extension, you need a new GL symbolic constant, like TEXTURE_MAX_ANISOTROPY. To achieve this, add #defines for them in mozilla-central/gfx/gl/GLDefs.h. Notice we use LOCAL_GL_ prefixes there to avoid some conflicts.

Adding Tests

Unfortunately, odds are fairly high that we don't have a test case for this particular extension! It would be very useful to write one, and even more useful to write one that can be added to the conformance test suite.

Other Remarks

  • MXR and DXR are useful code search tools.
  • Test your code by running the WebGL conformance test suite. (compare to a test run without your patch)
    Or as a mozilla mochitest: (assuming that you are in your mozilla-central directory, and that obj-firefox-debug is your object directory)
    TEST_PATH=content/canvas/test/webgl/test_webgl_conformance_test_suite.html make -C obj-firefox-debug/ mochitest-plain