Skip to content
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

[Refactoring]: Improve ZoneView caching in the presence of many sights #3747

Closed
kwvanderlinde opened this issue Nov 23, 2022 · 2 comments
Closed
Assignees
Labels
code-maintenance Adding/editing javadocs, unit tests, formatting. performance A performance or quality of life improvement

Comments

@kwvanderlinde
Copy link
Collaborator

Describe the problem

Maps do not perform very well when there are many tokens with sight, particularly when individual views are used. In particular, even deselecting tokens can grind to halt even if nothing has changed since the tokens were selected.

There seems to be a few things at play:

  1. The visible area cache in ZoneView is cleared too eagerly. Even though it can map distinct player views to their own areas, the entire cache is being cleared whenever the player view is changed (such as when selecting / deselecting tokens).
  2. The calculation of the visible area is pretty heavy. For each token with sight, we establish its visible area, which involves stacking up all the lights sources along with the token's sight to determine which areas are actually visible. When there are many such tokens, this is extremely expensive.

The improvement you'd like to see

First, more intelligent invalidation of ZoneView.visibleAreaMap. Unless something changes that impacts all views, the cache as a whole should not be cleared. In particular, it should be possible to change views without any invalidation of this cache.

Second, improve to the visible area calculations. We can factor out some common results that can be shared across tokens. For example, the heaviest part of the calculation is probably the need to stack up all the light sources and the token's sight. But that doesn't necessarily need to be repeated for all tokens, e.g., if there is no darkenss or sight multipliers in play, than all tokens would agree on the lit area. We could therefore combine that common result with each token's restriction on vision rather than recalculating everything from scratch for each token.

Expected Benefits

Performance would be much better when making heavy use of sights, which will improve the user experience. The caching improvement would avoid pauses when selecting and deselecting tokens, while the algorithm improvement would reduce the length of the pauses whenever the calculation need to be redone.

Additional Context

No response

@kwvanderlinde
Copy link
Collaborator Author

Found a problem that Expose Last Path doesn't do anything. Working on a PR to fix that up.

@kwvanderlinde kwvanderlinde added the performance A performance or quality of life improvement label Nov 3, 2023
@kwvanderlinde
Copy link
Collaborator Author

As this is a pure refactoring and we haven't had complaints yet, I'll close this off. Bug reports can be filed if anything comes up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code-maintenance Adding/editing javadocs, unit tests, formatting. performance A performance or quality of life improvement
Projects
Status: Done
Development

No branches or pull requests

1 participant