# JUCE 8.0.13 released **URL:** \ **Category:** News and Announcements\ **Created:** [May 19, 2026, 1:38pm UTC](https://forum.juce.com/t/juce-8-0-13-released/68851 "2026-05-19T13:38:24Z")\ **Posts on this page:** 13\ **Page:** 2
**Author:** ![attila](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/attila/32/11206_2.png) [@attila](https://forum.juce.com/u/attila)\ **Post date:** [May 30, 2026, 1:39am UTC](https://forum.juce.com/t/juce-8-0-13-released/68851/21 "2026-05-30T01:39:33Z")
Thank you for reporting. A fix has been released on the `juce9` branch > > > This change corrects an unintended change introduced in > 258203706cdfc1357effe8cc…752672b793cea37d. ---
**Author:** ![fuo](https://avatars.discourse-cdn.com/v4/letter/f/ba8739/32.png) [@fuo](https://forum.juce.com/u/fuo)\ **Post date:** [May 30, 2026, 6:21am UTC](https://forum.juce.com/t/juce-8-0-13-released/68851/22 "2026-05-30T06:21:21Z")
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. ---
**Author:** ![attila](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/attila/32/11206_2.png) [@attila](https://forum.juce.com/u/attila)\ **Post date:** [May 31, 2026, 4:24am UTC](https://forum.juce.com/t/juce-8-0-13-released/68851/23 "2026-05-31T04:24:18Z")
The fix has been pushed to `develop` > > > This change corrects an unintended change introduced in > 258203706cdfc1357effe8cc…752672b793cea37d. ---
**Author:** ![emezeske](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/emezeske/32/15528_2.png) [@emezeske](https://forum.juce.com/u/emezeske)\ **Post date:** [June 1, 2026, 2:07am UTC](https://forum.juce.com/t/juce-8-0-13-released/68851/24 "2026-06-01T02:07:49Z")
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): > [@\[Windows\] DPI scaling broken in JUCE 8.0.13 for some DAWs (renoise)](https://forum.juce.com/t/windows-dpi-scaling-broken-in-juce-8-0-13-for-some-daws-renoise/68923): > > PR to fix: > > > \# 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. ---
**Author:** ![fuo](https://avatars.discourse-cdn.com/v4/letter/f/ba8739/32.png) [@fuo](https://forum.juce.com/u/fuo)\ **Post date:** [June 7, 2026, 2:19pm UTC](https://forum.juce.com/t/juce-8-0-13-released/68851/25 "2026-06-07T14:19:05Z")
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. ---
**Author:** ![fuo](https://avatars.discourse-cdn.com/v4/letter/f/ba8739/32.png) [@fuo](https://forum.juce.com/u/fuo)\ **Post date:** [June 11, 2026, 2:59pm UTC](https://forum.juce.com/t/juce-8-0-13-released/68851/26 "2026-06-11T14:59:27Z")
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%). ---
**Author:** ![burns](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/burns/32/1473_2.png) [@burns](https://forum.juce.com/u/burns)\ **Post date:** [June 15, 2026, 8:00am UTC](https://forum.juce.com/t/juce-8-0-13-released/68851/27 "2026-06-15T08:00:09Z")
Hi, I believe 8.0.13 broke the Projucer’s “_Embedded Frameworks_” for the Xcode builds. Please see: > [@Projucer Embedded Frameworks broke between v8.0.12 and v8.0.13](https://forum.juce.com/t/projucer-embedded-frameworks-broke-between-v8-0-12-and-v8-0-13/68965): > > 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… ---
**Author:** ![fuo](https://avatars.discourse-cdn.com/v4/letter/f/ba8739/32.png) [@fuo](https://forum.juce.com/u/fuo)\ **Post date:** [June 18, 2026, 9:58pm UTC](https://forum.juce.com/t/juce-8-0-13-released/68851/28 "2026-06-18T21:58:36Z")
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). ---
**Author:** ![fuo](https://avatars.discourse-cdn.com/v4/letter/f/ba8739/32.png) [@fuo](https://forum.juce.com/u/fuo)\ **Post date:** [June 22, 2026, 6:52pm UTC](https://forum.juce.com/t/juce-8-0-13-released/68851/29 "2026-06-22T18:52:16Z")
In Renoise, 8.0.14 seems to fix the main issue (double scaling), but now sub menus do not open at the right position. ---
**Author:** ![emezeske](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/emezeske/32/15528_2.png) [@emezeske](https://forum.juce.com/u/emezeske)\ **Post date:** [June 22, 2026, 9:12pm UTC](https://forum.juce.com/t/juce-8-0-13-released/68851/30 "2026-06-22T21:12:53Z")
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. > > > \# 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. ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [June 30, 2026, 2:26pm UTC](https://forum.juce.com/t/juce-8-0-13-released/68851/31 "2026-06-30T14:26:15Z")
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: > If you discover any further issues, please let us know and I’ll take another look. ---
**Author:** ![emezeske](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/emezeske/32/15528_2.png) [@emezeske](https://forum.juce.com/u/emezeske)\ **Post date:** [June 30, 2026, 5:44pm UTC](https://forum.juce.com/t/juce-8-0-13-released/68851/32 "2026-06-30T17:44:59Z")
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.) ---
**Author:** ![emezeske](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/emezeske/32/15528_2.png) [@emezeske](https://forum.juce.com/u/emezeske)\ **Post date:** [July 1, 2026, 10:50pm UTC](https://forum.juce.com/t/juce-8-0-13-released/68851/33 "2026-07-01T22:50:11Z")
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: > > > \### 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. [Previous page](https://forum.juce.com/t/juce-8-0-13-released/68851.md?page=1)