raster performance improvements

[incanus]

Here is one possible improvement towards #103, though it's not done yet.

It moves from a std::forward_list for tiles to a std::map, binned by zoom level and constantly sorted (with custom comparator std::greater) per normal map behavior. Could try std::unordered_map but the sort here is negligible as it's among ~20 keys, tops (zoom levels).

Pro:

• This makes things faster, yet still not fast enough on retina iPad.

Con:

• Tile iteration logic is a bit more complex, though still decent.

@kkaefer @springmeyer I feel like I'm hitting the limits of my C++ knowledge here and spinning my wheels so I would appreciate some eyes. @springmeyer I also tried your suggestion of std::find(tiles.begin(),tiles.end(),...), which yielded a slight improvement but not as much as the move to map.

I'm going to work on some raster binding improvements now, which is showing as a higher bottleneck now that these improvements are in place, as well as grabbing #105.

[kkaefer]

Under what circumstances do you see the parent/children finding becoming an issue? This never appears in my performance profiles.

[kkaefer]

Why not stick all into a std::map<Tile::ID, Tile>?

[incanus]

Under what circumstances do you see the parent/children finding becoming an issue? This never appears in my performance profiles.

No, this looks great for me on everything except a retina iPad 3 fullscreen. The combination of other things going on to drive the display at larger size + so many textures is what causes issues, but we need to solve for this hardware. It's just not a matter of acceptable delay, either, it affects frame rate and gesture responsiveness.

[incanus]

Why not stick all into a std::map<Tile::ID, Tile>?

The Tile::ID is what is being compared anyway; I don't think this would help. Currently all of tiles are iterated, checking id against the needed tile. This would do the same thing.

The map approach at least bins them by zoom level.

[incanus]

One thing I am going to try next is to pre-set packed integers in the tile constructor, rather than on demand, and use those for the tile.id == id comparison to reduce three comparisons (z/x/y) down to one.

[incanus]

Under what circumstances do you see the parent/children finding becoming an issue? This never appears in my performance profiles.

@kkaefer To give you a sense, I just made two videos with Reflector. The frame rate loss you see in the iPad is real, not the video.

iPhone: https://dl.dropboxusercontent.com/u/575564/iphone_raster.mov
iPad: https://dl.dropboxusercontent.com/u/575564/ipad_raster.mov

And here's a representative profiling:

Here updateTiles takes longer than the actual render calls

And breaking it down, findLoadedChildren ranks 1 and findLoadedParent ranks 3

A CSV export of the profile (Instruments does this?): https://dl.dropboxusercontent.com/u/575564/Time%20Profiler%20-%20llmr_Run1.csv

[incanus]

My latest work here is on somehow seeing if HTTP connections need to be throttled. They can max out at 25-35 simultaneous connections, depending, and although the NSURLSession system is supposed to handle them appropriate to system load, that's still a lot, so it might be forcing the main thread / tile structure updating into reduced resources.

[incanus]

URL loads are not a bottleneck problem. I worked with local, cached tiles and wasn't able to get satisfactory performance, either.

Now I'm thinking that despite updateTiles() frequently ranking above other things (like painting) in time profiling, it might not be what's causing the perceived performance problems. I started looking for intense OpenGL calls, since all of them are on the main thread. The heaviest are all of the glTexImage2D() to upload raster textures to the GPU.

I experimented with not actually uploading textures and the performance is a lot better.

These uploads could be offloaded to a second OpenGL context and a background thread instead of being kept in the render loop, so that's my next approach.

[incanus]

Pausing this for a bit to get my head out of raster for a while, as this works well on smaller devices now.

[kkaefer]

I'm going to have a look at this as part of #101

[kkaefer]

Related tickets: #183, #122

[incanus]

Closing this as stale.

It moves from a std::forward_list for tiles to a std::map

Among other things, we do this already.