[Performance]: Light area calculation is slow for many lights

[kwvanderlinde]

Describe the Bug

When loading a map for the first time, the visible area is calculated. This is very slow when many lights are present, with almost of the time being spent combining light areas according lumens.

There seem to be two large factors that cause this the slowdown:

1. Despite being a multithreaded operation, a lock surrounds the most expensive part. This means the operation is effectively single-threaded, plus some lock overhead.
2. The code under the lock does a lot of converting Areas to Path2D and back again. This is expensive and we can avoid a lot of this work by only converting back to Area once all lights have been combined.

To Reproduce

1. Open the performance logs (Tool menu > Collect Performance Data).
2. Open the attached campaign file. It has a single map with many 144 light-bearing tokens.
3. Wait a while for the map to load. I have to wait over half a minute.
4. Observe that the first Timer ZoneRenderer.renderZone time since opening the campaign is high. I observed ~40s.
5. Select any token on the map.
6. Deselect the token and observe the same long delay.

Expected Behaviour

The provided map should be able to load in under 10 seconds in the same conditions.

Screenshots

No response

MapTool Info

1.11.4

Desktop

Linux Mint 20.2

Additional Context

Here is the test map: manyLightsTest.zip. Just rename it to .cmpgn instead of .zip once downloaded.

Other actions can trigger the a full recomputation of the visible area. E.g., selecting a token and then deselecting it will result in the same ~40s delay.

[Phergus]

Testing. Big performance gain.

1.11.5:
2. 9678 ms calcs-1
3. 9677 ms ZoneRenderer-getVisibleArea

Dev Code:
2. 483 ms calcs-1
3. 483 ms ZoneRenderer-getVisibleArea