Did that, no avail.
I tried this fix as well. The issue itself is not resolved but can now only be reproduced when the application window is resized to a smaller size. It is reproducible even with demo projects. You need to resize the application window to a smaller size for the issue to manifest again.
OK, thanks for letting me know. I’ll take another look.
Please could you supply the following information:
- On what display scale do you see this problem? Is it still only present at 125% scale?
- In which example project do you see problems?
- How are you resizing the window to a smaller size? Are you just dragging the window border with the mouse, or are you doing something else? Maybe a gif or recording would help to illustrate the problem.
So far, on Windows 10 @ 125% display scaling, I’m unable to trigger any issues when resizing the window. Are you completely sure that you’re using the latest JUCE develop branch?
This is still with the AudioPluginDemo VST3? I can’t repro that behaviour here.
This isn’t a new change, this has been the case since JUCE 6, or perhaps even before that.
I’m wondering whether some other aspect of your setup changed when you updated your computer. e.g. REAPER has a mode that can be toggled from + -> Compatibility settings -> HiDPI compatibility mode when floating window. This mode, when enabled, will bypass JUCE’s built-in DPI scaling, and will instead render with logical pixels mapped directly to physical pixels, and then will scale-up the resulting image to an appropriate size. Could this option have been toggled accidentally?
Scaling may also be affected by the JUCE_WIN_PER_MONITOR_DPI_AWARE preprocessor definition. If the value of this definition changed at some point, this would affect the observed scaling behaviour. For new projects, it’s a good idea to leave this undefined, or set to 1 (enabled).
I wonder as well which version of REAPER you’re using for testing. If you’re not currently on the latest version, do you see any changes after updating to 7.27?
-
Yes, with AudioPluginDemo VST3 (haven’t updated to your latest fix though)
-
Regarding getScreenX etc. On Mac it seems not otherwise i would have had the same issue as on Windows. If Mac and Win behave differently this is an inconsistency. And as i wrote before, it did not do so on my Win 10 build, but on Windows 11 it does. Need to investigate a bit more.
-
I will check the HiDPI setting in Reaper. Though i leave everything on default because i assume that this is the way most users use DAWs. So Reaper is set to what every is the default. Also never touched
JUCE_WIN_PER_MONITOR_DPI_AWARE. Have to check Reaper minor version though not a lot is to be expected.
You were right, I had checked out the develop branch and had built Projucer myself, so it was up to date with version 8.0.4. However, I forgot to manually update the module paths to the new JUCE version.
I tried it again today, and indeed, now it works correctly. I can no longer reproduce the bug, even with different scaling levels.
Thanks a lot for you support and time!
1 Like
Windows 10, main monitor at 200% scaling, second monitor HD (100% scaling).
Standalone apps are experiencing resizing issues, as already described earlier in this thread — jumpy/jerky resizing of components and corrupted borders around the main window.
In addition to my app, Projucer is also affected (I’ve attached an animated GIF showing the issue).
For reference, JUCE 6 and the latest JUCE 7 builds of Projucer do not have this problem and work correctly.
UPDATE:
Today I rebuilt the apps again using both the JUCE 8 development branch and the 8.0.7 branch — and the issues are no longer present.
I have no idea what I did wrong yesterday, but the GIF is proof of the problems I was experiencing at that time.
Any ideas or hints as to what might have happened?
As a starting point I’d recommend trying to work out what was changed between yesterday’s builds and today’s. Which JUCE commit did you use yesterday? Was it the 8.0.7 tagged commit, or a later commit?
It might help to consider the following points:
- Did you build in the same configuration (debug/release) in all cases?
- Did you build from scratch each time?
- Did you reboot the computer, connect/disconnect displays etc. in the meantime?
Yesterday and today, I built my app and Projucer using VS2019 on Windows 10, both in Debug and Release configurations, first with the JUCE 8 development branch latest commit, and then with the latest JUCE 8.0.7 commit from the JUCE repository.
I also tried using “Rebuild Project” several times. Both monitors are the same as before, with identical resolutions and scaling settings.
Now that I think about it, the first thing I noticed today was that the executable built yesterday was working fine. I immediately checked whether it was a JUCE 7 build, but it turned out to be a JUCE 8 build — the same one that didn’t work yesterday.
As weird as it sounds, I honestly have no idea what could have changed, except that the computer was turned off and on once since yesterday.
Will dig further…
Maybe it’s worth mentioning that yesterday, after I tried JUCE 7 and confirmed it was working, I switched back to JUCE 8 to build the apps again and verify that the issue was still there — and it was. However, the same apps (executables) appear to be working fine today, at least as far as I can tell.
Another day — so far, so good. I’ve been experimenting with the same things as over the past two days, and everything is working as expected. I haven’t been able to reproduce any of the previous issues.
Let’s hope it stays this way — or even better, that I eventually figure out what I did wrong in the first place.
Good day,
I’m having the same issue on Windows 10 with the latest 8.0.10 build …
The same issue happens on previous 8.* builds as well …
This obviously happens only when using native title bar.
In my case it happens regardles of display resolution set and with each scalling option (100% - 350%).
Single monitor 27”.
I was wondering if there is some fix or at least any workaround for this? (apart from usnig custom titlebar on Windows 
)
Thank you.
Unfortunately I haven’t been able to reproduce this issue, so it’s difficult to track down the problem. Please could you provide the following info:
- Which Visual Studio version are you using to build? If you’ve got several installed, do you get the same results with each?
- What graphics card is your system using? Are you using up-to-date drivers? If not, does updating help?
Sorry, I totally forgot to mention that I was using a windows binary, downloaded directly from Juce web site. I wasn’t building the demorunner.
But at that moment, my app built with Visual Studio, behaved the same. (I’m using VS Community edition 2022 (64bit) 17.14.11).
Today I’ve decided to re-test everything properly, with all possible display settings/scaling sizes and modes, and that issue is gone …
I can’t recall when exactly it was resolved … when I just opened the NVIDIA settings app or tried to change Scaling from Aspect Ratio to No Scaling … but from that time the issue was gone…
My video card is GeForce RTX 2060 super, the driver is Studio 577 (Jul 22, 2025), DirectX 12.0
I’ve decided to continue testing all possible options and found one case where the issue still can be reproduced on any resolution, scaling size or option.
The test case requires a JUCE application to have setResizeLimits bigger than the selected screen resolution or scaling size.
It should be bigger vertically or horizontally with or without scaling (e.g. you can set resolution 800x600 or 1280x768 with scaling 150% or bigger).
I understand that this is an edge case, but want to mention it for future references.
Please let me know if you need any additional info.
Thank you.
Sorry, I don’t understand what this means. Please could you let us know the exact setResizeLimits() call you’re making, along with your physical screen resolution and scaling factor?
Sorry for the slow reply … wasn’t feeling well these days …
Here is an example:
DetachableWindowBase::DetachableWindowBase(const juce::String& name,const juce::String& configPrefix,bool allowCustomTitleBar): DocumentWindow(name, juce::Colours::black, DocumentWindow::closeButton | DocumentWindow::minimiseButton),configPrefix_(configPrefix),useCustomTitleBar_(allowCustomTitleBar){
setUsingNativeTitleBar(!useCustomTitleBar);
setResizable(true, true);
setVisible(false);
...
setResizeLimits(RESOLUTION_MINIMUM_WIDTH, minimumHeight, desktopBounds.getWidth(), desktopBounds.getHeight());
setSize(RESOLUTION_MINIMUM_WIDTH, minimumHeight);
}
The issue happens for me when I’m using my recommended resolution (3840x2160) with scaling 300% or higher.
But recently I discovered another some really wierd thing that I think will be hard to explain
When I was playing around with auto resizing a window. I tested some logic that will auto resize the window using some calculations to keep a specific scaling factor and this logic was called inside the resized() function of a component.
When I triger the resized() call (by resizing the app window with a mouse) it somehow breaks the JUCE globally after couple of actions …
What I mean by that is that even though the issue triggered within my app, which was then closed, affects all JUCE apps that will be started later (e.g. JUCE DemoRunner). And I need to reboot my computer to clear that issue.
And this happens only when a system`s native title bar is being used.
With custom title bar no issues at all.
Sorry if I wasn’t clear enough.