AAX: Fix editor size on Windows when DPI scaling moves off the master scale

[emezeske]

Summary

On Windows, the AAX wrapper reports the editor size to the host in the wrong units when the DPI factor is carried by the window's platform scale rather than the desktop master scale. The host receives logical-sized bounds and clips the physical-resolution editor. This is reproducible in Pro Tools at any Windows display scale above 100%: the plugin UI overflows its window and is clipped.

Regression

This is a regression introduced by 8bbe48c ("Windows: Use 1.0 as the master scale if DPI awareness is available"). That commit changed Desktop::getDefaultMasterScale() to return 1.0 whenever DPI awareness is available:

 double Desktop::getDefaultMasterScale()
 {
-    if (isPerMonitorDPIAwareProcess())
+    if (setDPIAwareness())
         return 1.0;

     return getGlobalDPI() / USER_DEFAULT_SCREEN_DPI;
}

Previously only per-monitor-aware processes got a master scale of 1.0; a system-DPI-aware process (which is how Pro Tools runs) got getGlobalDPI() / 96 (e.g. 1.25), and the DPI factor therefore lived on the master scale. After 8bbe48c the master scale for those processes is 1.0 and the DPI factor lives on the window's platform scale (ComponentPeer::getPlatformScaleFactor()) instead. The peer-based paths (VST3, mouse/window positioning) were updated to match, but the AAX host-bounds conversion still reads only the master scale, so it silently became a no-op for system-DPI-aware hosts and started reporting logical bounds as physical.

Root cause

ContentWrapperComponent::convertToHostBounds scales the editor's logical size into the host's physical pixels by multiplying by getGlobalScaleFactor() (the desktop master scale) only:

auto desktopScale = Desktop::getInstance().getGlobalScaleFactor();

Pro Tools runs system-DPI-aware, so after 8bbe48c its master scale is 1.0 and its platform scale is the monitor DPI (e.g. 1.25). With the master scale alone, convertToHostBounds reports logical bounds as physical, so the host sizes the view too small while the editor still paints at physical resolution - hence the overflow and clipping.

Fix

Multiply by both the global (master) scale and the window's platform scale, so the full logical-to-physical factor is applied regardless of which term carries the DPI factor. The product is invariant to where 8bbe48c leaves it: pre-8bbe48c1 the master scale held the DPI factor and the platform scale was 1.0; post-8bbe48c1 the split is reversed. Either way the product is the true logical-to-physical scale, so this restores the pre-regression sizing without depending on which term the DPI factor is stored in.

Testing

• Pro Tools on Windows at 100%, 125%, and 150% display scaling: the editor now fills its window with no clipping, and resizing behaves correctly.

[juce-push-bot]

This pull request has been mentioned on The JUCE Forum. There might be relevant details there:

https://forum.juce.com/t/juce-8-0-13-released/68851/33