Pin layer rendering performance

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. Render pins layer to an intermediate texture and only recompute this texture on pin changes
  2. Limit number of pins returned by overpass

(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?

Assigned to
2 years ago
10 months ago
bug high-priority pending-release refactoring release_1.2

~mil 2 years ago

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.

~mil 2 years ago

Routes / connecting lines are quite slow to render and noticeably effect performance even with small routes.

~mil referenced this from #61 1 year, 4 months ago

~mil 1 year, 4 months ago

Plan is to use EvictionHashMap and render pins to XYZ tiles (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.

~mil REPORTED FIXED 10 months ago

Fixed in 1.2.0 release.

Register here or Log in to comment, or comment via email.