Thorsten said:
@Cavni, Brian C. just tested Dead in Thay Ooze Grottos (improved light layer) with me after this fix, and the issue with extreme sluggishness of moving tokens is confirmed, CPU-bound not GPU-bound. It might be this requires a fix to the size of the Ooze Grottos map, in addition to the light layer fix, or it might be this map exposes an area of improvement for AFoW.
It's a little odd this is CPU-bound, not GPU-bound. Can you add that to the list, please? I'm happy to share the redone map with the roll20 team, in any way that works for you, including transmogrifying it into a campaign, or making someone DM in the test/reference campaign I'm using.
Moving a token around in that game was unlike anything I had experienced before. It took several seconds when dragging a token for it to even start moving, and the movement stuttered, for lack of a better word. Where my page (described below) would see CPU increase to 90% and GPU to 100%, in this game the CPU was maxing out and the GPU stayed under 5%. As far as I understood (and Thorsten can correct me), the settings were:
My token: Has Sight only.
The page: AFoW, DL with enforce LoS, restrict movement, and global illumination
I took that knowledge back to my test page that has 100 light-emitting tokens controlled by the player and rejoined it as a player. This page has the following settings:
Tokens: Has sight, Emits 20/20 light
Page: size 100x100, has a few DL boxes on the map, has 100 of the player tokens spread around the map.
This setup yields CPU 90% and GPU 100% when the player moves one of the tokens. So I had an idea. The main difference between my map and Thorsten's (aside from a lot more DL lines) was that global illumination was on. I switched global illumination on for the page and it instantly locked the page for both the player and GM browser tabs. When reloading the page, it took minutes to get back in. The page showed the same behavior as in Thorsten's game: very slow for a token to start moving and stuttering movement. I had to go into another page as the GM and turn global illumination back off for that page to get the page working again.
I then tried this with a simpler 32x20 page with the same settings and only 1 light-emitting player token. CPU/GPU was 70%/80% with global illumination off and 70%/40% with global illumination on. It seemed strange that GPU utilization would go down when I could see more of the cavern map with global illumination on. I set the AFoW view distance on the token to 20 feet to match the token's light. As soon as I did that, the CPU/GPU utilization matched whether global illumination was on or off.
My theory is that a workaround introduced in March is the culprit. Normally, a token with vision but no AFoW view distance has the view distance silently set to 0. To make at least some maps work with AFoW and DL, a behavior was introduced that those tokens would instead have the blank view distance interpreted as infinite (or very long) when global illumination is on. It seems like having the AFoW algorithm search the entire map is having the Ooze Grotto's page grind to a halt.