attila
May 30, 2026, 1:39am
21
Thank you for reporting. A fix has been released on the juce9 branch
committed 07:39AM - 28 May 26 UTC
This change corrects an unintended change introduced in
258203706cdfc1357effe8cc… 752672b793cea37d.
fuo
May 30, 2026, 6:21am
22
So no fix for JUCE 8, even though this is a regression just introduced, with a one-line fix?
I’d expect bugs to also be addressed in the JUCE 8 branch until JUCE 9 is officially released.
8 Likes
attila
May 31, 2026, 4:24am
23
The fix has been pushed to develop
committed 03:01AM - 31 May 26 UTC
This change corrects an unintended change introduced in
258203706cdfc1357effe8cc… 752672b793cea37d.
2 Likes
I believe the 8.0.13 release broke DPI scaling in some DAWs including Renoise (it gets applied twice, so JUCE’s UI is inflated extra large):
master ← emezeske:dpi-fix-2026-05-31
opened 02:03AM - 01 Jun 26 UTC
# Fix double-scaled plug-in editors on Windows in hosts that send a redundant co… ntent scale
## The problem
On a high-DPI Windows display the plug-in UI has to be drawn bigger (e.g. 1.25x at 125%). There are **two independent ways** a plug-in can be told to do that:
1. **The OS way**: the window is marked per-monitor DPI-aware, and Windows scales it.
2. **The host way**: the host calls `IPlugViewContentScaleSupport::setContentScaleFactor(...)`.
Some hosts do **both at once for the same factor**: the window is DPI-aware *and* the host also sends a content scale equal to the monitor's DPI. When that happens, if the desktop scaling is e.g. 1.25 JUCE applies the 1.25 twice and the editor renders at ~1.56x.
I observed this in Renoise, where the plugin window is too large and scaled up too much.
## Why it works in most hosts but breaks in Renoise
Most hosts pick **one** mechanism: per-monitor-aware hosts (Reaper, Cubase, etc.) rely on the OS and send no content scale (or 1.0). **Renoise** (and **Tracktion Waveform**) are DPI-aware *and* call `setContentScaleFactor` with a factor equal to the monitor DPI, so the same scale is counted twice. It is not a Renoise-specific bug; it is any host that supplies a content scale a DPI-aware window does not need.
## Why old JUCE worked and 8.0.13 broke it
This regressed in **`fcf1971122` ("Plugin Client: Change scaling mechanism on Linux/Windows plugins")**, which changed *how* the host content scale is applied:
- **Before 8.0.13:** the host content scale was applied as a **top-level `AffineTransform`** on the editor, independent of the window's OS/peer DPI scaling. The two lived in separate channels and did **not** stack, so a redundant host scale was harmless.
- **In 8.0.13:** the host content scale is applied as the window's **platform scale** (`ComponentPeer::setCustomPlatformScaleFactor`), and `convertToHostBounds` now multiplies by `desktopScale * platformScale`. The host scale and the window's own DPI scaling now occupy the **same channel**, so a host scale that equals the DPI gets multiplied in on top of it, leading to double-scaling.
## The fix
In `JuceVST3Editor::setContentScaleFactor`, ignore any content scale that is **at or below the window's own DPI scale** (`getScaleFactorForWindow`). The OS already applies that much to a DPI-aware window, so such a factor carries no new information; only a factor that **exceeds** the window's DPI represents extra scaling the host actually wants.
This is correct in every case:
- **DPI-aware window, redundant scale (Renoise / Waveform):** ignored: the OS's single DPI scaling stands.
- **DPI-unaware window:** `getScaleFactorForWindow` returns 1.0, so a real host scale (> 1.0) is never mistaken for redundant and is still applied.
- **Cubase 10 integer-scale workaround** (the existing block right below): its integer factor never equals the fractional window DPI, so that path is untouched.
- **Genuine host zoom beyond the monitor DPI:** a factor greater than the window scale is still honored.
It restores the pre-8.0.13 result (a single DPI scaling) without reverting the new mechanism, and is a no-op for any host that was not already sending a redundant content scale.
3 Likes
fuo
June 7, 2026, 2:19pm
25
8.0.13 completely changes the ways DPI is handle in plugins on Windows (for the better), so that kind of issue was to be expected.
I really hope we will get a final JUCE 8 release that fixes all that. We are still within JUCE 8’s life cycle, right?
The way this was handled with JUCE 7 was a bit brutal honestly, with fixes left hanging in develop.
4 Likes
fuo
June 11, 2026, 2:59pm
26
Found an issue introduced with this patch: in PluginDoctor when showing the plugin UI the window is too big for a fraction of a second (eg twice as big when DPI scale is 200%).
burns
June 15, 2026, 8:00am
27
Hi,
I believe 8.0.13 broke the Projucer’s “Embedded Frameworks ” for the Xcode builds.
Please see:
Hi all,
one of our apps uses the Projucer’s “Embedded Frameworks” for the Xcode builds.
It was working fine with JUCE 8.0.6. Then we updated to JUCE 8.0.13 and it could no longer build, producing a “sealed resource is missing or invalid” error and a bunch of “file missing” for headers specified in the embedded framework directory.
So we downgraded to 8.0.12 and it built fine again.
I did a git blame on jucer_ProjectExport_Xcode.h, where the embeded framework paths are read, and saw that ther…
fuo
June 18, 2026, 9:58pm
28
Another issue to report with this version: in Reaper (and maybe other DAWs) using the Direct2D rendered, I get sporadic flashes when the plugin resize its window itself (eg a collapsing panel).
1 Like
fuo
June 22, 2026, 6:52pm
29
In Renoise, 8.0.14 seems to fix the main issue (double scaling), but now sub menus do not open at the right position.
1 Like
FWIW, running my plugin with my PR for the scaling fix (which is different how the JUCE folks chose to fix it), sub-menus appear in the correct positions in Renoise. Maybe this will offer a clue to what’s still wrong with the JUCE code.
master ← emezeske:dpi-fix-2026-05-31
opened 02:03AM - 01 Jun 26 UTC
# Fix double-scaled plug-in editors on Windows in hosts that send a redundant co… ntent scale
## The problem
On a high-DPI Windows display the plug-in UI has to be drawn bigger (e.g. 1.25x at 125%). There are **two independent ways** a plug-in can be told to do that:
1. **The OS way**: the window is marked per-monitor DPI-aware, and Windows scales it.
2. **The host way**: the host calls `IPlugViewContentScaleSupport::setContentScaleFactor(...)`.
Some hosts do **both at once for the same factor**: the window is DPI-aware *and* the host also sends a content scale equal to the monitor's DPI. When that happens, if the desktop scaling is e.g. 1.25 JUCE applies the 1.25 twice and the editor renders at ~1.56x.
I observed this in Renoise, where the plugin window is too large and scaled up too much.
## Why it works in most hosts but breaks in Renoise
Most hosts pick **one** mechanism: per-monitor-aware hosts (Reaper, Cubase, etc.) rely on the OS and send no content scale (or 1.0). **Renoise** (and **Tracktion Waveform**) are DPI-aware *and* call `setContentScaleFactor` with a factor equal to the monitor DPI, so the same scale is counted twice. It is not a Renoise-specific bug; it is any host that supplies a content scale a DPI-aware window does not need.
## Why old JUCE worked and 8.0.13 broke it
This regressed in **`fcf1971122` ("Plugin Client: Change scaling mechanism on Linux/Windows plugins")**, which changed *how* the host content scale is applied:
- **Before 8.0.13:** the host content scale was applied as a **top-level `AffineTransform`** on the editor, independent of the window's OS/peer DPI scaling. The two lived in separate channels and did **not** stack, so a redundant host scale was harmless.
- **In 8.0.13:** the host content scale is applied as the window's **platform scale** (`ComponentPeer::setCustomPlatformScaleFactor`), and `convertToHostBounds` now multiplies by `desktopScale * platformScale`. The host scale and the window's own DPI scaling now occupy the **same channel**, so a host scale that equals the DPI gets multiplied in on top of it, leading to double-scaling.
## The fix
In `JuceVST3Editor::setContentScaleFactor`, ignore any content scale that is **at or below the window's own DPI scale** (`getScaleFactorForWindow`). The OS already applies that much to a DPI-aware window, so such a factor carries no new information; only a factor that **exceeds** the window's DPI represents extra scaling the host actually wants.
This is correct in every case:
- **DPI-aware window, redundant scale (Renoise / Waveform):** ignored: the OS's single DPI scaling stands.
- **DPI-unaware window:** `getScaleFactorForWindow` returns 1.0, so a real host scale (> 1.0) is never mistaken for redundant and is still applied.
- **Cubase 10 integer-scale workaround** (the existing block right below): its integer factor never equals the fractional window DPI, so that path is untouched.
- **Genuine host zoom beyond the monitor DPI:** a factor greater than the window scale is still honored.
It restores the pre-8.0.13 result (a single DPI scaling) without reverting the new mechanism, and is a no-op for any host that was not already sending a redundant content scale.
reuk
June 30, 2026, 2:26pm
31
Thanks for reporting the new issues. It’s really tricky to cover all the possible usage scenarios for Windows hi-dpi! Hopefully this change resolves the problems you’re seeing:
committed 12:22PM - 30 Jun 26 UTC
If you discover any further issues, please let us know and I’ll take another look.
2 Likes
It’s a huge pain. The only option is to maintain NFRs for as many DAWs as possible, and any time the DPI code is touched, test every single one of them manually. It’s basically never safe to make changes to DPI code without doing a full manual test run across at least 15 DAWs.
(My plugin does native window stuff including Vulkan surfaces, etc, so I am intimately familiar with how painful this is! Every single change to anything remotely DPI related has to have a human look at the plugin in every DAW on Windows. There’s really no other option.)
1 Like
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:
develop ← emezeske:pr/aax-windows-dpi-scale
opened 10:39PM - 01 Jul 26 UTC
### 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.
1 Like
