I would like to ask you about a new bug that has been introduced with JUCE version 8.0.1 or later.
When resizing a JUCE-based application window on a monitor with a zoom level of 125% or higher, the content becomes misaligned, creating a “falling apart” effect in the application view.
This issue is reliably reproducible when resizing the window slowly.
Steps to Reproduce:
Use a Windows 10 computer with a display set to 125% zoom or higher.
Open any JUCE demo project or the Projucer with JUCE version 8.0.1 or later (including version 8.0.4).
Slowly resize the application window.
Additional Information:
The issue can be reproduced on any default JUCE demo project or the Projucer.
The problem does not occur with JUCE versions prior to 8.0.1.
Thank you in advance for looking into this! Please let me know if any additional information or examples are needed to help resolve this issue.
Yes, I am using multiple screen sizes, including a HiDPI screen. However, I have also tested the issue on non-HiDPI screens, such as Full HD(1920x1080), and on higher-resolution screens like 2K(2560x1440) and 4K(3440x1440, 3840x2160), but the issue persists across all screen sizes and resolutions.
Nevertheless, I need to revise my statement that this problem occurs even at zoom levels greater than 125%. It is present only at the 125% setting!
Rescaling on Windows with Juce 8 is completely broken. When moving a plugin window from a screen with 100% to another with 150%, everything falls apart completely. Components are still in the place where they should be at 100% and that doesn’t work well when painting is done through OpenGL (custom shaders).
Add: Not only when moving from one screen to another. Even when simply opening it on hiDPI. So anything bigger than 100% is not working on Windows right now.
Run the Projucer, then you can either go to File->Open… and open one of the example .h files, or go to File->Open Example->Plugins and select an example from that list.
Ok, did some tests. Since we use OpenGL and our own painting method it cannot be compared. Checked the AudioPluginDemo and it did not show the crazy deformation.
But: When moving between screens with different scalings, size is not maintained. Meaning: I rescale the window to a certain size on 100% screen. Move it to a 150% screen and then back to the 100% screen. Plugin window is now significantly smaller than before the moving. It shouldn’t be like this, right?
I am on Windows 11 and yes, it is the AudioPluginDemo VST3i in Reaper. Built with Juce 8.0.4.
On my system i pull the Window to have half the width of the screen which is at 100%, just to have a measure. Then i pull it over to the screen with 150% where it already resizes a bit without releasing the mouse. Then when releasing the mouse it resizes another bit, becoming even bigger. Until that it seems ok because now it’s width is about 2/3rd of the screen (both 1080p screens). Now when i pull the window back to the 100% screen it becomes smaller, but much smaller being now around 1/3rd of the width, not half width.
OpenGL context in our plugins is attached to the PluginEditor. Working perfectly across all systems with Juce 7. Also working perfectly on Mac with Juce 8. Only Windows is utterly weird with Juce 8.
I can confirm that something is going wrong with drag & drop on differently scaled displays on Windows machines. I posted my problem 2 weeks ago and it seems to me that these problems are interconnected.
Please see my original post: Drag & drop bug in JUCE 8 (Windows)
I just found out that it is the other way around. The screen is on 125% actually and when the component is moved there, it is too big. It seems it is increased in size 2 times (once by simply moving and another time when releasing the mouse key: 1.25*1.25 = 1.5625). Then when moving back the window gets resized by way more than factor 1.5625, but i haven’t figured it out yet. It seems to respect the size limits, at least on 100% though.
I also found the issue with my OpenGL part. getScreenX() and getScreenY() for components suddenly return the physical pixes instead of logical pixels. I compared with Juce 7 and it does it there also now. Since a few days back i updated my main build machine from Windows 10 to 11, it might have something to do with that. The juce7 version of our plugins built on Win 10 scale fine on Win 11. But the juce7 or 8 version built on Windows 11 have that new behaviour with the above mentioned two functions.
I had this problem when migrating from JUCE 7 to JUCE 8.0.3 and it was generally in all cases. Windows 10, 150% scale. Strangely enough a Windows restart helped. It almost seemed like there was something triggering it and from then on corrupted all created windows after. Probably something Direct2D related.
We’ve now released a fix for the original issue reported in this thread, specifically where the window’s client area could end up overlapping the caption bar and/or partially un-rendered. I was only able to observe this problem on Windows 10 at 125% scale. Other scale factors do not trigger this issue, and Windows 11 does not appear to have this problem. I’m reasonably sure this is a bug in Windows itself, so the change is more of a workaround than a proper “fix”.
Please try out this change and let us know how you get on.
