Lighting causes mouse lag with 4.1 on Mac, maybe to do with old LOS?

[HywelPhillips]

Hi,

The new lighting is great. When it is tuned up I'm really looking forward to using it.

I have noticed a slowdown issue with 4.1. This is on an iMac 2017 4.2 GHz core i7, 48 GB RAM, Radeon Pro 8192 MB, running off the built in SSD, MacOS High Sierra 10.13.6.

When everything is turned on, inevitably, performance suffers, which is expected.

But it is also hitting user interface performance outside of screen updates - mouse movement becomes laggy and jerky, which it ought not to do. Mouse clicks become very imprecise as a result. It's not the fastest Mac in the world but it's not a total slouch, and other demanding applications like editing or compressing 4K videos don't cause this system-wide mouse judder even when exercising CPU and GPU fully. So I think there's something a bit wrong with how the code is doing things compared with other applications and I suspect it is something to do with old-version-of-FGU LOS definitions.

The problem seems particularly marked with token lock on, having the tokens do their move path animation. The culprits seem to be line of sight and lighting.

Here's an example on a wilderness map. You can see how much the token slows down with those options turned on. What you can't see is that this slowdown affects everything, even mouse movement. I had to have nine goes at capturing the video because the mouse lag gets so back that I kept mis-clicking.

For sure this is a stressful test for the system. There's a big-ish map on a retina screen, masked FX on the water, FX myst, FX Time of Day over the top, a token with both light emission and darkvision, and terrain line of sight blockers. Nonetheless, there's only five lights (ambient, three torches and the wraith token), the number of occluder sections is pretty normal for an outdoor map, and there are only two tokens on the map. So I don't think it is entirely unreasonable to try with maps like this.

The issue for me is not the rendering lag or jerky frame rates, it that it spills over into affecting the mouse movement to the point that the system becomes almost unusable. I find myself moving windows constantly because the mouse pointer hasn't caught up with the movement by the time I click the mouse.

Interestingly, it doesn't seem to be using the CPU of the system. The fan's not coming on, and CPU usage is like 8% (barely taking anything from a single core).

GPU usage is pegged to the Max even with /vsync 4, though.

I haven't tried it on my iMac Pro yet which has a beefier GPU and is on Catalina instead of High Sierra, because that's my production machine. But I think there's some bug or need for tuning here because my regular iMac can run 3D graphics games at fairly high spec without hitting this mouse-judder system slowdown issue.

https://youtu.be/w5tIjJJHC9Q

This was in an otherwise pristine vanilla 5E campaign with just DMG, PHB, MM, Phandelver and my own module of battlemaps loaded. No extensions.

The battlemap had its LOS defined under an older version of FGU. I tried a fresh battlemap imported from a clean JPEG and didn't seem to encounter the same issue - GPU pegs out at 100% still even in VSYNC 4, but the mouse movement is not affected to anything like the same extent. Then I tried the original JPEG for this battlemap re-imported and quickly re-positioned most of the elements.

It's still a bit jerky rendering, pegging GPU at 100% and having tokens slow to move when GM approved, but doesn't produce the mouse lag and the Mac system remains responsive.

I cleared the LOS data from the original map from my module and re-did it, and it seems to have sped it up, too.

So my conjecture is that there's something FGU doesn't like with the old LOS definitions, maybe?


Cheers, Hywel

[Ulric]

I have only done a few minutes of testing 4.1 using the 5e ruleset with a WOTC paid module and it felt very sluggish. I plan to to do some in depth testing this weekend and will post my results.

[HywelPhillips]

I can report that this problem does not occur on my iMac Pro under Mac OS Catalina with this week's release.

GPU usage is high but it doesn't kill the mouse movement or affect the system outside of FG, and /vsync 4 makes the system good and snappy again.

So it looks like lighting is usable for me now

It still seems pretty slow on the older machine on older version of the OS but I'm not so concerned now that I have a working solution.

Cheers, Hywel

[Ulric]

I have noticed that FGU can go from working as expected to sluggish if I have chrome running. When this happens I can see a process called chrome rendering is running in the background. I can eliminate the sluggishness by quitting Chrome and using Safari. FGU with lighting normally uses between 10-20% CPU but will go over 50% if Chrome is running. Over all I’m very pleased with how well it’s running on an 8 year old MacBook Pro.

[Moon Wizard]

Chrome is a memory hog; so I bet that the main memory is having to be shared by Chrome and forcing swapping to disk and/or reloading of images.
(i.e. just running half a dozen tabs in Chrome uses 2GB of memory on my machine.)

Regards,
JPG

[HywelPhillips]

Whatever was causing the issue on my older iMac doesn't seem to be memory - I was running FGU on a clean boot-up with nothing else running and plenty of free memory. It's the GPU usage that seems to be off the scale. It's still way less snappy on that machine than on my newer iMac Pro (with a more powerful GPU and faster everything but main CPU clock speed).

Cheers, Hywel

[Moon Wizard]

@HywelPhillips,

We pushed a new build today with some performance improvements for LoS. Could you try your map again?

In addition to trying with the latest build; if you're still having performance slowdowns, can you try this chat command to see if it helps?
(reduces resolution of LoS/FoW/blurring in return for performance)

/imagequality [0-3]
(where 0 is default, and higher numbers are reducing resolution 75/50/25%)

Thanks,
JPG

[HywelPhillips]

That's fantastic.

On the iMac High Sierra, the global system slowdown is fixed and no longer occurs even with vsync 0 imagequality 0.

The "magic combination" is vsync 1 imagequality 3 which produces high GPU usage but very snappy and crisp responses from FGU - feels like almost a different program. It can now handle me throwing a lot of stuff at it. vsync 4 lowers the GPU load, but doesn't provide as snappy a response to things like locked token movement.

On the iMac Pro Catalina I find the same story. It copes a bit better with imagequality 0/1/2 than the iMac (more GPU memory may be responsible?) and with vsync 1 imagequality 3 it feels like a completely different experience, super responsive and snappy and looks absolutely beautiful.

Even with default settings it's perfectly usable now on both machines, and with a little fine tuning it is stunning. Great job, thank you guys!

Cheers, Hywel

[Ulric]

I am also happy to report that "The "magic combination" is vsync 1 imagequality 3 " holds true for my Macs too! It was the difference between an almost unplayable session to a snappy and responsive frustration free session. without these setting the player computer would be a second or two behind the GM computer in screen updates. Zooming in and out the map was choppy. Now the GM and Player screens are in sync and map zooming works properly.