consider rendering offscreen

[derhuerst]

I haven't looked at the exact implementation yet, so forgive me if this is already the case.

It would be possible to render the map offscreen, e.g. in a worker process and then display it. By doing this, the UI wouldn't be blocked that long. Scrolling would have to be disabled or a new rendering attempt started (with the new zoom level) on scroll/move events.

[rastapasta]

You're very right, right now there is no threading implemented - just a breeze of asynchrony.
Considered it as well and would love to see it implemented at some point!

[derhuerst]

btw looking at the source code, it seems really easy to pull out the src/Renderer into a worker. 👍 for the structure!

[derhuerst]

Renderer doesn't need output, right?

[rastapasta]

Well seen, the output is a deprecated left-over from before :)

Next to the time spent on downloading, the main render-bottleneck currently is the initial processing of a fresh vector tile. The layers' features get filtered (no matching style -> out) and indexed via rbush in _loadLayers - its the reason for the performance drop when (int)zoom changes on feature rich 'fresh' areas, even when the tiles are already cached locally.

The Renderer itself currently waits for all corresponding rbush trees to then request all features in the current bbox. Just putting this whole logic in a worker wouldn't change much (as far as i can see), IMHO the downloading&processing logic would be a better match for it. Meaning: instead of the Renderer waiting for all (up to 4) tiles being initially processed, it could incrementally render them as soon as they are processed by a worker. One more dream: if the parent tile in an above zoom level is already rbush'ed in memory, it could be rendererd stretched while the more-detailed zoom-corresponding tiles are processed and rendered as soon as they're available.

That's such a beautiful piece of logic to be implemented :)

[edit: typo]