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.
Since draw is the only tile operation that we defer, the tile queue can be an array of tiles and queue handling can be simplified. We now use the beforedraw event to defer drawing, and remove all occurrences of a tile from the tile queue when we draw it.
Instead of layers that want to defer tile drawing having to override the tile's draw method, layers can now abort drawing by returning false from a beforedraw listener, and later call draw(true) to draw the tile directly, without clearing it first.
Instead of giving the function a bound, a scope, a property to update
and a callback, only give the bound and a callback.
When the url is retrieved by getUrlAsync, simply call the callback
with the url as argument and let the caller manage this.
A problem introduced with 5fda8835da can easily be solved by re-adding a check for imgDiv and a strict type check for useIFrame. Thanks @elemoine for pointing out that there could be a problem.