HTML and CSS Reference
In-Depth Information
Draw!
The creation and filling of canvasTiles occur at initialization time for your app. Later on, in order to render, you simply
need to determine if a given canvasTile is visible to the view-rect, using box-box intersection code (see Chapter 16).
If it is, draw it as though it were any other tile:
function onDrawMap(ctx)
{
//aabb test to see if our view-rect intersects with this canvas.
for(var q =0; q < gMap.canvasTileArray.length; q++)
{
var r1 = gMap.canvasTileArray[q];
if(r1.isVisible())
ctx.drawImage(r1.cvsHdl, r1.x-gMap.viewRect.x,r1.y-gMap.viewRect.y);
}
}
Results
With caching, the performance improvements can be drastic. Frame rate on lower-end machines can shoot through
the roof, although this comes at the cost of large memory overhead.
For a large map, your canvas will incur approximately 4MB per 1,024×1,024 tile. For example, a map of
6,400×6,400 pixels would yield a 7×7 array of tiles, landing you at 196MB of data; 196MB, however, is huge, unyielding,
and maybe too uncompromising, especially if the map sizes increase. It would be great to mix the performance of
Tiled caching with lower memory restrictions.
Because the preallocation takes up so much memory, it keeps you from being able to distribute specific large
map sizes to players with machines that cannot handle the memory requirements. If you're working with a strong,
memory-full device, then, by all means, this technique works great, but for more restricted devices, you may need an
alternate solution.
Using a Free List of Canvases
So, let's review.
The forward-rendering path is great on memory, because it uses only the loaded texture atlases and draws from
them each frame. Performance suffers here, however, owing to the recomputation of large portions of the screen with
each frame, wasting precious central processing unit (CPU) cycles.
Conversely, the caching path is great on performance, drastically reducing the number of draws per frame.
However, this technique is horrible on memory, taking up a large portion of your the available space on your
application (app).
This situation requires a middle-of-the-road compromise between memory and performance. The goal is to have
some notion of cached tile content, but maybe not the entire map, all the time.
To achieve this, you create a relatively small array of
canvasTile
objects (the size of the pool is up to the
developer or, more specifically, the constraints of the device on which you're working. You use these canvases as a
pool for the visible screen. As a section of the screen becomes visible, you try to cache the map into a tile and use the
tile for as many frames as possible.
Once you run out of free tiles to use, you evict the oldest tile (that is, the tile that was filled the longest time ago),
replacing it with the new content.
