Having the TileManager remove an image from the DOM, then setting the
cached image, and then having to position it felt a bit awkward. With the
new beforeload event, the setImage method and putting renderTile before
positionTile, providing the cached image feels way more natural.
Using the Timeline tab of the Chrome Developer Tools, no significant
difference of Paint events can be observed when requestAnimationFrame is
used. So I agree with @elemoine that there is no need to introduce
asynchronous behavior here.
Calculating pixel positions from origin and grid index causes alignment
issues in the grid. By going back to incremental positioning, we get a
result without blank spaces between tiles again.
Performance improvements are achieved by using requestAnimationFrame when
a tile's visibility changes, and by not starting with a blank image when
creating a new tile image. It seems that even Firefox does not show a
loading placeholder when the tile is made visible in an animation.
For this to be useful (i.e. so listeners can see/modify the tile url), a change in Tile.Image is required so we do not fire the loadstart event before we have the url to load.
Having to call two methods to get complete feature information (id and data) is cumbersome. The `getFeatureInfo` method returns an object with both feature id and data.
The tile now has responsibility for resolving feature ids and fetching feature data given x, y pixel offsets with getFeatureId and getFeatureData methods. The layer has corresponding getFeatureId and getFeatureData methods that take a map location, lookup the appropriate tile, and delegate to the tile for the rest of the work.
To get IE7 support, the OpenLayers.Format.JSON parser should be used. This leverages the native JSON.parse method where available. It does add extra weight to UTFGrid builds. However, as of this commit date, we lose large portions of US govt agencies when we exclude IE7.
I would think there would still be an error thrown here. Will put together a test to determine for sure, but I'd think that the default GeoJSON parser used by the protocol would choke on the UTFGrid json.
