In CoreGraphicsPixelData::createImage, image data was copied from a
BitmapData created from the Image passed into the function.
The BitmapData instance didn't keep track of the size of the buffer it
pointed to, so the buffer size was computed by multiplying the
BitmapData height by its line stride. However, if the BitmapData pointed
to a subsection of an image, the `data` pointer might be offset from
the allocated region, and `data + lineStride * height` would point past
the end of the allocated region. Trying to read/copy this range would
cause a heap buffer overflow at the end of the range.
This change adjusts BitmapData so that it keeps track of the size of the
allocated region. Taking a subsection of an image should subtract the
data pointer offset from the size of the allocated region.
The bug was triggered on Monterey where a pressure of 1 is reported
while a mouse button is being held down. This caused an extra drag
event being triggered between mouse down and up events, even if no
movement occurred.
This issue affected windows with JUCE titlebars. When dragging the
window back and forth between two displays with different DPI settings,
the window could sometimes end up with the wrong size.
It looks like setting new window bounds inside the WM_WINDOWPOSCHANGED
message was occasionally causing the system to lose track of the correct
scale for the window.
As a byproduct of this change, JUCE should no longer receive reentrant
calls to handleDPIChanging.
With this patch applied, the DemoRunner should build under MinGW, and be
(nearly) feature-complete compared to the MSVC build.
Specifically, when building with MinGW:
- Adds support for accessibility
- Fixes build issues in the juce_video module
- Fixes a link issue in the VST3 wrapper when VST3_CAN_REPLACE_VST2 is
defined
- Adds support for the new-style native FileChooser
- Tidies up some other low-severity warnings
Known issues:
- Direct2D rendering is still not supported when building with MinGW due
to ABI compatibilities.
This mirrors the behaviour on Linux, where maximizing a window always
fills the screen, even if a constrainer is active.
If you don't want to allow your component to fill the screen, disable
the maximize button in the window's titlebar when creating the window
(i.e. ensure DocumentWindow::maximiseButton is not set in the required
buttons).
This new factoring is a bit more typesafe, as it avoids casting
internals to void*.
It also allows cursors to scale appropriately on high resolution
displays on Windows.
The scaling machinery in the component peer was causing problems for
hosted plugin views. Scaling the plugin view size requires close
collaboration between the plugin and the host, and it's important for
the host to have exact control over the size of the plugin's view. The
removed code in the HWNDComponentPeer was modifying the sizes of
embedded plugin windows, which would often leave them at an incorrect
size.
The faulty behaviour was especially noticable with plugins that do not
support DPI-aware behaviour. I tested with the following plugins (VST2 +
VST3), which should all now display correctly in the AudioPluginHost,
and assume the correct size when opened on hi-res displays, or dragged
between displays with different scale factors:
- Plogue AlterEgo
- U-He Hive 2
- FabFilter Pro-C
- Native Instruments Supercharger
- Surge
Sometimes, changing the bounds of the window inside the DPICHANGED
handler can cause further DPI change events to be processed. Previously,
the scaleFactor set by the "inner" events was also being used when
notifying listeners about the "outer" events, leading to graphical
glitches.
An effect of the bug was that VST2 views in the AudioPluginHost would
occasionally render with an incorrect size and position after dragging
them between displays with different scale factors.
With this change in place, we only notify listeners and update window
bounds once there are no DPI changes in progress.
- Add AlertWindow::show() and showAsync() methods that take a MessageBoxOptions argument
- Add NativeMessageBox::show() and showAsync() methods that take a MessageBoxOptions argument
- Update the DialogsDemo to demonstrate the new methods
- Deprecate AlertWindow::showNativeDialogBox() in favour of the NativeMessageBox methods
- Pass button strings specified in MesssageBoxOptions to native dialog boxes correctly
- Use modern TaskDialog on Windows for the native dialog box where available
When bridging 32-bit/64-bit plugins on Windows, the plugin is hosted in
an auxilliary process, and the plugin's editor is embedded into an HWND
owned by a different process (the plugin host).
Previously, the `isForegroundProcess` check would fail for bridged
plugins, because the foreground window may belong to the DAW, rather
than to the auxilliary hosting process.
This patch adds an additional check, to find whether the same process
owns both the foreground window, and the window which embeds the
PopupMenu's target component. In this case, we avoid immediately
dismissing the PopupMenu.
This change ensures that popup menus will be dismissed when hosted
plugin windows are moved, even when these plugin views are themselves
hosted inside JUCE views, like those used in the AudioPluginHost.
falkTX
reuk
Attila Szarvas
ed