MacShrike The lowest layer of my map always has tiles everywhere, and I found out that just resetting and refilling them is faster then cleverly updating the displaylist.
Then you were probably updating the displaylist in a non-optimal manner. E.g. you could do it like so:
Say you need 10 * 10 so 100 tiles to cover the display area. Add them all to a Sprite, and change the Sprite’s x and y to scroll them.
At some point they scroll far enough so some tiles fall of an edge. Take the tiles which are no longer visible, move them to the opposite edge by updating their x or y. If necessary update their texture, by updating the texCoords of each tile (assuming they are all from the same TextureAtlas as they should be for best performance). So to handle a fall-off-edge event it only needs to update the positions and data of 10 tiles (in practice it needs to upload the vertex data for all 10, not just the texCoords).
With a MeshBatch though you update the positions and texCoords for the tiles, copy the data to the MeshBatch with AddMeshAt, then it has to upload the data for all 100 tiles as the MeshBatch has no way to track which vertices have changed, and only upload those.
I.e. updating a MeshBatch should be much more expensive, not faster. Frankly it should still work fine – updating 10 or 100 Quads every few frames is well within Starling’s capabilities. But the fastest way to do it should be with separate Quads, not a MeshBatch.