HTML and CSS Reference
In-Depth Information
// Bind the texture
gl.bindTexture(texture.getType(), texture.getBinding());
this.boundTextures_[index] = texture;
}
}
GraphicsContext.prototype.initializeTexture = function(texture) {
// Bind the texture to the pipeline
this.setTextureAt(0, texture);
var gl = this.gl_,
type = texture.getType();
// Set the default sampler data
gl.texParameteri(type, gl.TEXTURE_MAG_FILTER, gl.LINEAR);
gl.texParameteri(type, gl.TEXTURE_MIN_FILTER, gl.TEXTURE_LINEAR_MIPMAP_NEAREST);
}
The
GraphicsContext
retains information that is contained within the underlying state machine. WebGL allows
multiple textures to be bound to the pipeline at the same time, with each one residing in a separate texture unit. This
information can be kept track of by holding an array of textures with the value held corresponding to the specific
texture unit. The way to specify that texture unit is to make a call to the API,
activeTexture
, which specifies the index.
This information also has to be retained.
When setting a texture to a given unit, the first thing to check is if that texture is already bound to the given
location. This is done first, as the current texture unit only needs to be changed if the texture will actually be replaced.
The check of the texture unit is performed when the texture is due to be replaced, because the texture unit may have
been modified. During the process, whenever the internal WebGL state is modified, that same modification is applied
to the context. This ensures that the underlying states are kept in lockstep with each other.
When building up the renderer further, it's just a matter of extrapolating the same concepts to encompass other
objects: only a single program can be bound to the pipeline at a time, the layout of the vertex buffer can be retained,
and a uniform's value should be changed only when a different input has been provided. All this, and more, needs to
be reflected within the rendering context. Once these issues are handled, the interaction with WebGL is optimal at
this level.
Debugging WebGL Usage
To verify that the API is being used properly, there are multiple techniques that can be implemented. Those interested
in unit testing the graphics layer can do a mock of the
WebGLRenderingContext
and record the calls being sent. If a call
passes through that shouldn't have occurred, then the test should fail. Which framework to use is really dependent on
developer choice, as there are a ton of frameworks available in JavaScript. The Closure Library provides a unit-testing
and mocking framework, whereas QUnit is a popular unit-testing framework that can be coupled with
Sinon.js
for
mocks. With Dart the choice is easier; it comes with a robust unit-testing library that also handles mocks. Writing
unit tests is outside the scope of this chapter but is a great way to verify that no redundant calls are being made in an
automated fashion.
What is more useful during the actual application development is to view the calls being made during a frame,
by taking snapshots of what is actually happening. The most robust way to accomplish this is through the WebGL
Inspector, a Chrome extension that allows the entire WebGL context to be viewed (see Figure
9-2
). When WebGL
content is available, a GL icon appears in the address bar, which is used to toggle the extension on and off.
