Right now the rendering of the pins (and labels) is done on each render cycle; this slows things down quite a bit with large number of pins. With around 50 pins the speed difference isn't noticable. With 300 pins; there is quite a slowdown.
Potential solutions:
(1) is likely the best solution, would invalidate cache on zoom level caching. Main question is how to handle this since probably can't do a 'single' texture as I suppose that would exceed the texture size limit on the GPU.
One idea is could chop up into multiple textures (similar to tiles) and rework tile system to support multiple layers of tiles; Alternative idea: blit to a surface in ram and then transfer to texture only pieces we need on render. Question: is a large large SDL surface with blank space (e.g. transparent) large in ram or is it effieciently compressed?
Limited number of results for (2); the potential long-term solution here will increase in complexity of rendering logic, needs to be thought through carefully.
Routes / connecting lines are quite slow to render and noticeably effect performance even with small routes.
Plan is to use
EvictionHashMapand render pins toXYZtiles (with a transparent background) as a texture. Thus similar logic to the base OSM tiles rendering can be re-used. Pin rendering will calculated on a per-tile-basis and the cache will be wholesale cleared on adding/removing/altering pin state (more detailed invalidation can be implemented later and even wholesale cache invalidation will be more efficient then re-rendering all pins on each cycle as is done currently).Work-in-progress status is on branch
blitpins-texturecache.
Fixed in 1.2.0 release.