Hi there!
I’m trying to switch from starling to openlfl and I have a serious problems with understanding of openfl’s batching:
If I want my applications to work quickly, I need to use texture atlases for graphics. In starling it’s a quite simple: if I use few images with the same atlas in a row, then I have one draw call (even they are in a different display containers).
In the openfl it’s a more difficult. There is an additional object tilemap which, in theory, should solve the problem of batching. But as it turned out, tile objects can not use flash-like display containers to create hierarchical objects.
I do not really understand why openfl api has diferent objects bitmap and tile, although in fact they do the same thing, why can not unify api? For example, a bitmap could use atlases or so on.
Maybe I do not understand something? Any more or less serious application should use batching, and so it should give up the flexibility of display containers.
Hello 
The first OpenGL renderer we had in OpenFL had automatic batching of standard display objects, so that we could reduce the number of draw calls.
This made our renderer much more complicated, introduced bugs, and usually hurt performance instead of helping it.
The BitmapData + Bitmap approach to rendering usually results in one separate image per display object. It is rare that you would have two Bitmap objects, sharing the very same BitmapData, rendered next to each other. If you did want this, a different API (without scrollRect, filters and other display list features) would enable us to more easily enable batch rendering.
Perhaps we could consider something like a TileContainer. Another option would be to use ordinary Sprites and other display objects, and have each hold a Tile reference for use with Tilemap. Your display list objects could preserve your object hierarchy for you, but be separate from the actual rendering.
I would be happy to discuss the Tilemap API, but we don’t want to change the Bitmap API. For what it is worth, we have designed the Lime Image API (which backs the BitmapData class) to be able to be a sub-rectangle of a larger ImageBuffer, which could provide this functionality, but this is not something that has been fully developed
Yes it would be great! It would also be nice to be able to detect mouse clicks on tiles.
Thanks for your answer!
We are missing some methods I had originally intended for Tilemap, such as getTileAt (x, y), which would help with hit detection
