[Refactoring]: Reduce number of times the exposed area is calculated

[kwvanderlinde]

Describe the problem

When using Individual FoW, the exposed area is recalculated every time fog needs to be rendered. This includes every time the zone is panned or zoomed, even though that has no bearing on the exposed area.

Additionally, we calculate the exposed area twice. We should calculate it at most once per frame because it can be really expensive for complicated FoW.

The improvement you'd like to see

ZoneRenderer would cache the exposed area associated with a given PlayerView. If that view ever changes, the exposed area would be recalculated. Also, if FoW is ever explicitly flushed, then the exposed area would also be recalculated.

Expected Benefits

The first frame that renders a given set of exposed areas will still be expensive, but most frames would be very cheap. Panning and zooming the map would be much more responsive.

Additional Context

The expensive call that calculates the exposed area is zone.getExposedArea(view) in ZoneRenderer.renderFog(). While we only call that method once, we actually duplicate its logic a little further down when in the calculation of tempArea. I.e., tempArea and combined are always equal as far as I can tell, so there is no need to recalculate tempArea or union it with combined as we do.

For comparison, I made a prototypical code change (no cache invalidation) to measure the potential impact. Using the sole map in this test campaign, I saw an improvement from ~270-350 ms to <20ms for renderFog in most frames. Just removing tempArea gives a 2x speed up (naturally) and caching provided the remaining benefit.

[kwvanderlinde]

There's also some room to clean up the various cases under the renderFogArea timer. If I'm reading things right:

1. view.getTokens() is only null for a player that doesn't own any tokens or - if Individual Views is off - if there are no PCs with sight. So when we don't need a combined view, we should be able to not render anything in this case.
2. In the non-null case for view.getTokens(), the combined/non-combined cases are identical and don't need to be distinguished.

[kwvanderlinde]

There's one more place where we repeatedly recalculate the exposed area: AbstractAStarWalker.calculatePath(). Not bad when only moving one token, but can get sluggish when there are several.

[kwvanderlinde]

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.