Current for 6.x-2.0-alpha3

Obviously there are many points at which advanced users will want to push the
limits of what the OpenLayers module can do. In many cases, these changes can be
make without any 'hacks' to the module, and before hacking, it is highly
recommended to think about ways that changes could be incorporated into the
module proper via patches.

# Performance

The largest performance hit of OpenLayers at the moment seems to be in the very
large size of the OpenLayers.js library. The real route to fixing this problem
is by narrowing down the set of components included in the Javascript file. In
order to do this:

## Manually

    svn checkout http://svn.openlayers.org/trunk/openlayers/ cd openlayers/build

edit full.cfg or lite.cfg to include the components your map uses.

    python build.py [yourcustomized.cfg]

This will produce a compacted, slimmed OpenLayers.js file.

After doing this, make sure to set the ImgPath and ThemePath in the OpenLayers
administration - these are per-preset settings. The OpenLayers library guesses
the location of its style.css and images, so if you make a compacted
OpenLayers.js in an otherwise empty folder, it will fail in this task and have
blank images and a nonfunctional ZoomBox control (the red 'zooming box') will
not appear.

## Map Performance

Using multiple domain names for layers will [dodge the browser connection
limit](http://trac.openlayers.org/wiki/OpenLayersOptimization) and allow more
tiles to load in parallel. However, this has a bad interaction with the default
buffer setting, making tiles outside the viewport load first in many cases, so
buffer should be set to 0 if multiple urls are enabled.

# Custom Behaviors

If behaviors similar to those included are necessary, just clone the behaviors
and create a tiny new module that includes the copy. The same goes for layers,
etc.