HTML and CSS Reference
In-Depth Information
Figure 21-1.
Simple WebGL image gallery
The gallery application isn't very complex, but it's designed to stress a couple of aspects of the texture-loading
library in order to compare various approaches:
•
It continuously downloads new images. This stresses the amount of bandwidth used, and it
favors image files that are as small as possible.
•
Textures are constantly being swapped in and out of memory, so the app favors textures whose
video memory footprint is as small as possible.
Although this particular example is fairly contrived, the requirements are not unheard of for real-world
applications. For example, the virtualized texturing techniques used in id Software's Rage (
http://rage.com
)
, on
both game consoles and iOS, rely on a constantly-updated texture pool and well-compressed images on disk to
display a large world in which every surface is uniquely textured. While most WebGL apps won't require that level of
complexity, there are very few apps that wouldn't benefit from faster load times and less memory usage.
Browser-Supported Images
Before diving into the details of texture compression, let's first review the formats that browsers support natively. This
may be old news to many developers, but it's still interesting to look at the numbers involved. Since we're looking
at reducing load times, we'll focus our attention on the file sizes produced by each format, taking into account the
capabilities and limitations of each.
For the gallery application, I took several pictures at various locations around the Google campus in Mountain
View, as seen in Figure
21-2
. The images were then saved in the various browser-supported formats using GIMP's
default export settings for each. Each image is 1024×1024 pixels with no opacity information. I've picked three of them
to use for the comparison.
