HTML and CSS Reference
In-Depth Information
Listing 9-2.
WebGLRenderingContext
, IDL Portion
interface WebGLRenderingContext {
void drawArrays(GLenum mode, GLint first, GLsizei count);
void drawElements(GLenum mode, GLsizei count, GLenum type, GLintptr offset);
}
The Web IDL specification outlines the interface available to the scripting language. This specification is used by
the browser to determine how data should be marshalled between them and the virtual machine. In general, this layer
is generated automatically during the build process, though some bindings are created by hand. The result of this
operation within Blink is the
V8WebGLRenderingContext
, the first layer that the WebGL call passes through.
WebGL puts additional restraints on top of the OpenGL ES specification to ensure a secure environment, and
the purpose of the
WebGLRenderingContext
is to verify that this contract is not broken. In the case of a
drawArray
call, the browser will verify that the arguments passed in are correct by checking that a valid offset and count were
supplied and that the current render state is legitimate. If everything checks out, then it's off to the next layer, the
WebGraphicsContext3D
.
From here on, the explanation gets very Blink specific, as it has its own ideas on how compositing should be
accomplished within a browser. Because of this, some of the finer points will be glossed over;for more information,
refer to the Google document
GPU Accelerated Compositing in Chrome
(
http://www.chromium.org/developers/
design-documents/gpu-accelerated-compositing-in-chrome
), which goes into considerable detail on the
compositing architecture.
As mentioned earlier WebGL is not the only portion of the browser that utilizes hardware acceleration; Blink may
promote portions of the page to render on the graphics card. The
GraphicsContext3D
class handles the needs of any
portion of the browser requiring hardware accelerated rendering, furnishing an interface very similar to OpenGL.
At some point in the rendering process, the underlying OpenGL implementation has to be hit, yet that does not
actually occur on the same process that the WebGL command originated in. Instead, the interaction with the graphics
processing unit (GPU) is architected to occur on a completely different process. The aptly named GPU process
handles the hardware-accelerated rendering, which receives its marching orders through the renderer process. The
WebGraphicsContext3D
populates a command buffer in a shared memory location that can be accessed by both
processes, thereby giving the GPU process the required steps to render the scene properly.
Over on the GPU process side, the populated command buffer is vetted yet again. This is for security purposes,
as the GPU process does not trust the renderer process, because the GPU process has no way to determine if it was
compromised when loading a site. Once verified, each command is shipped off to the OpenGL implementation of
the platform. For platforms other than Windows the command reaches the graphics card's driver. On Windows the
command goes through an additional transformation by the Almost Native Graphics Layer Engine (ANGLE) library,
which converts the OpenGL commands into their DirectX counterparts. Only after all these steps does the WebGL
command reach the actual graphics card.
These steps occur whenever a WebGL call is made. This overhead cannot be avoided and is essentially the
penalty you have to pay for doing three-dimensionality in the browser. However, this cost is not a deal breaker; it just
means that one has to be mindful of how the API is being used in order to maximize performance. What that boils
down to is minimizing the number of calls made to the API while rendering the scene. To accomplish this at this low
level, the inner workings of WebGL need to be illuminated.
How WebGL Works
The most important thing to know about WebGL is that it is a state machine. The vast majority of the commands
available will modify either the entire state of the rendering or the internal state of an object provided through WebGL.
This knowledge is key to minimizing the number of calls made by the application.
To illustrate this point a simple scene can be profiled. One of the easiest examples, a “hello world” of sorts for
WebGL, is the spinning cube rendered with a texture (see Listing 9-3). Although not a solid, real-world example, the
cube showcases how calls can be reduced, owing to state being retained.
