New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consider rendering offscreen #3

Open
derhuerst opened this Issue Apr 26, 2017 · 4 comments

Comments

2 participants
@derhuerst
Contributor

derhuerst commented Apr 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rastapasta

rastapasta Apr 26, 2017

Owner

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!

Owner

rastapasta commented Apr 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@derhuerst

derhuerst Apr 26, 2017

Contributor

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

Contributor

derhuerst commented Apr 26, 2017

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

@derhuerst

This comment has been minimized.

Show comment
Hide comment
@derhuerst

derhuerst Apr 26, 2017

Contributor

Renderer doesn't need output, right?

Contributor

derhuerst commented Apr 26, 2017

Renderer doesn't need output, right?

@rastapasta

This comment has been minimized.

Show comment
Hide comment
@rastapasta

rastapasta Apr 26, 2017

Owner

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]

Owner

rastapasta commented Apr 26, 2017

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]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment