Optimizing WebGL Usage - HTML5 Game Development Insights - page 147

Rather than relying on WebGL to enumerate the current state, the application itself should keep track of its status
by mirroring WebGL's own state machine. By so doing, redundant calls can be prevented.

Building the Renderer
When building a large application, it's best to partition different subsystems into layers that handle specific
functionality. This separates concerns and offers a singular component that can be tested and verified. Building the
graphics subsystem involves wrapping the WebGL API into something friendlier to work with higher up within the
program. This is also the level at which the API usage can be optimized.
Although the creation of a renderer that binds the whole of WebGL is a topic worthy of an entire tome, a smaller
piece of the puzzle can be examined to learn how to go about building the larger whole. How the renderer deals with
textures internally can provide that insight.
At a very high level, WebGL allows

• creation and deletion of objects

• manipulation of the underlying objects

• setting of the rendering pipeline

The code in Listing 9-4 begins to sketch out an implementation of this layer.

Listing 9-4. Graphics Library

function GraphicsDevice(gl) {
this.gl_ = gl;
this.context_ = new GraphicsContext(gl);
}

GraphicsDevice.prototype.createTexture2D = function() {
var binding = this.gl_.createTexture(),
texture = new Texture2D(this);
texture.setBinding(binding);

// The texture is not complete, and therefore not usable until
// after the parameters have been set
this.context_.initializeTexture(texture);
return texture;
}

GraphicsDevice.prototype.deleteTexture = function(texture) {
var binding = texture.getBinding();

this.gl_.deleteTexture(binding);
texture.setBinding(null);
}
//------------------------------------------------------------
function GraphicsResource(device) {
this.device_ = device;
this.binding_ = null;
}