- Required when the deployment target is macOS 15+
- As the ScreenCaptureKit framework isn't available on all supported versions
of Xcode it's dynamically loaded
When handling WM_NCCALCSIZE, we reduce the size of the client area when
the window is maximised. If we don't do this, then the client area
matches the top-level window area, which is larger than the display's
safe area. As a result, the window appears too large, and the edges are
obscured under the edges of the display.
After reducing the client area in WM_NCCALCSIZE, the client area is no
longer equal to the top-level window area, so getBounds() must be
updated to return the window's *client* area rather than the top-level
window area.
When the display goes to sleep IDXGIOutput::WaitForVBlank returns S_OK
immediately causing the VBlankThread to consume a core entirely with the
VBlank related messaging.
To limit this problem, we use the same technique as Chromium presently
does, and we sleep for 1 ms, if the time between the last two VBlank
events was less than a ms. This limits the VBlankThread messaging rate
of about 50.000/s on an Intel 13600 to 1000/s.
Without this change, the mouse state was not always updated after
releasing the mouse, leaving the current modifier keys with the
left-mouse-button bit set. This was particularly evident in standalone
plugins, where clicking the 'options' button in the titlebar, then
immediately clicking the titlebar could "stick" the window to the mouse,
making it impossible to interact with the window normally.
This reverts commit adc63cecb1.
Reverting this commit is only a temporary measure to facilitate a stable
release of JUCE 8. Further work on this feature will continue on
develop, and will likely be included in a future release of JUCE 8.
Resizing using window manager functionality (e.g. clicking and dragging
in the non-client area) will send WM_SIZING to the window, which in turn
will enable continuous repainting in the D2D renderer until the resize
operation ends.
Continuous repainting is required in order for the window to display
correctly during the resize. Without continuous repainting, some frames
may not be completely painted, and may display with black areas,
producing a flickery effect.
When a resize is controlled entirely by the client, e.g. using the
corner resizer in the AudioPluginDemo standalone, WM_SIZING is never
posted. Instead, we assume that if the window has captured the cursor
during a setBounds call then it is probably resizing. We enable
continuous repainting in this case, and stop repainting once the window
releases the mouse.
An alternative appropach would be to add some kind of start/stop resize
API to ComponentPeer. I'm currently reluctant to do that because the
ComponentPeer API is already so large.
Previously, the UnitTestRunner example in the DemoRunner would fail on
any tests that included ScopedJuceInitialiser_GUI, as DeletedAtShutdown
objects would be destroyed too early.
We avoid modifying window controls in modal situations if possible.
Doing as much as [window setStyleMask: [window styleMask]]; for a
PopupMenu window will make it invisible on MacOS when the plugin is
hosted in an external subprocess.
This fixes a regression caused by
fb14118771.
