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.
3 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…
