JUCE 8.0.13 released

emezeske · July 1, 2026, 10:50pm

I believe I found another issue with the hi-dpi changes, when running plugins as AAX in pro-tools. I have prepared a fix for this one as well:

github.com/juce-framework/JUCE

AAX: Fix editor size on Windows when DPI scaling moves off the master scale (#1679)

develop ← emezeske:pr/aax-windows-dpi-scale

opened 10:39PM - 01 Jul 26 UTC

emezeske

+17 -7

### Summary On Windows, the AAX wrapper reports the editor size to the host i…n 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 8bbe48c1 ("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: ```diff 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 8bbe48c1 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: ```cpp auto desktopScale = Desktop::getInstance().getGlobalScaleFactor(); ``` Pro Tools runs system-DPI-aware, so after 8bbe48c1 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 8bbe48c1 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.

Topic		Replies	Views
The JUCE 8 Preview branch is available now! News and Announcements	186	8738	June 10, 2024
Melatonin Inspector: inspect your JUCE components ala Figma/Web Inspector Development	27	2664	March 30, 2025
I wrote a bit about "jank" in JUCE General JUCE discussion	22	2476	March 8, 2025
JUCE 8 Nightmare: Windows performance dramatically reduced! General JUCE discussion	62	2015	January 27, 2025
v1.24 General JUCE discussion	32	1310	February 10, 2006

JUCE 8.0.13 released

Purchase

Discover

Learn

Support

About

Events

JUCE 8.0.13 released

Related topics

Purchase

Discover

Learn

Support

About

Events