Issues with setGlobalScaleFactor on Windows standalone in latest dev?


#1

Hi, has anyone notices any issues with this?

The code I use for scaling is:

auto& desktop = Desktop::getInstance();
desktop.setGlobalScaleFactor( scale );
// do stuff to resize main window

This continues to work on OSX and has worked on Windows up until recently. Now when scaled to anything other than 1.0 the mouse doesn’t track controls correctly and sometimes the display is rendering incorrectly. Not sure whether this is to do with HDPI changes recently.

Anyone else noticed any issues? I can do a video to demo if that’s useful.


#2

Yeah we’re aware of the issues and are working on getting a fix out. It’s related to the recent hiDPI support changes.


#3

great thx - let me know when it’s done and I’ll test.


#4

Hi, is there an eta for this or a quick fix to undo the problem? thx


#5

You can disable the hiDPI support for the time being by disabling the JUCE_WIN_PER_MONITOR_DPI_AWARE flag in the juce_gui_basics module settings in the Projucer.


#6

I had report as well that something broke in recent version of Juce with users that use my own app scaling factor (that uses setTransform on the main component) in combination with the windows one. It used to work in previous Juce versions.

Thanks !


#7

Is this supposed to be fixed with commit from ed95 on the 19th of September ?

Thanks !


#8

Yeah that commit should have fixed a few bugs with hiDPI support on Windows, with the global scale factor being one of them.


#9

Looks like there are still issue. (using the trunk)
We have reports of graphical issue when using OpenGL renderer that use to work fine couple of month ago.
This happens when the Windows global scale is different than 100%
Weirdly this happens only in plugin mode and we don’t use the Juce plugin wrapper.


#10

Disabling JUCE_WIN_PER_MONITOR_DPI_AWARE fixes the issue.


#11

Probably related to the scaling applied twice.In the app and in juce_OpenGL_win32.h
Don’t know much what would be the correct fix.