Turn off vsync throttling when macOS hardware sleeps

[elijah-semyonov]

Speculative fix for a freeze issue.

[igordmn]

Thanks!

I left important comments need to be discussed.

[igordmn]

When the system wakes up, we need to notify the window to redraw the content. If system calls the AWT function paint(), it will redraw it. But can we guarantee that? If not, we should send a signal to AWT here.

[igordmn]

It seems the fix isn't about disabling redrawing, but about disabling vsync. In this case, no need to notify. But will we have unlimited FPS, and should stop drawing in case of sleeping?

[elijah-semyonov]

The issue is about deadlock on the conditional variable encpsulating vsync state. I can't reproduce that so my speculation is to destroy this mechanism temporarily while the device is sleeping.
I have an idea that have some really funny race-condition, where the logical screen for the window changes mid-flight due to some OS-level reconfigurations (flickering when connecting a display/waking up), so we wait on vsync from the screen which no longer exists/and AppKit didn't gracefully changed the screen to the existing one, but I have no idea currently how to fix that so I'd better try this solution and see if it fixes the issue.

[elijah-semyonov]

Potentially, it can indeed cause discarded drawables (because of redundant redraws, the initial issue that vsync mechanism fixed) if multiple were presented during a single hardware vsync after the the sleep notification, but that's an edge case that I bet will not affect the users

[elijah-semyonov]

macOS has less strict policy about drawables management and metal commands issuing from what I've observed, so stopping drawing altogether doesn't seem to be needed for correctness. Plus the AWT logic will also suspend at some point, hopefully.

[igordmn]

vsync also prevents unlimited FPS, which can load GPU/CPU. Do this code run for some time after sleeping?

[SergeevPavel]

I've noticed one more strange thing, not sure that it's related with this changes, but anyway. Usually we call performDraw() and waiting for vsync on our special blocking dispatcher. But in the problematic stack traces I see that we came from JComponent#paint and through redrawImmediately we call performDraw and block EventDispatchThread until we get vsync. I'm not sure how often Swing calls the paint method, but blocking (not suspending) on EventDispatchThread may lead to poor performance because it's used not only for rendering but also for user event processing and performing callbacks that update UI related state.
So, the question, do we really need to wait for vsync when JComponent#paint is called? May we draw without waiting for vsync or maybe at least unblock paint and offload blocking to blockingDispatcher?