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.


#12

The only way to fix it on my Windows 7 system is to disable OpenGL. Disabling JUCE_WIN_PER_MONITOR_DPI_AWARE doesn’t do anything that I can see on Windows 7.

Is there any update as to when this might be fixed?


#13

Any ETA on fixing this? I’m having to disable OpenGL to get around this issue.


#14

Can you be more specific? Does this only happen on Windows 7 or are later versions of Windows also affected? Which plug-in formats, and in which DAWs?


#15

This is a stand-alone application. No DAW or Plug-in required or used.

JUCE 5.3.2; Windows 7; Works as expected.
JUCE 5.4.0; Windows 7; Fails as described.
JUCE 5.4.1; Windows 7; Fails as described.
JUCE 5.4.1; Windows 10 Pro; Works as expected.

I hope this helps.


#16

OK, so just to be clear this is only happening when global scale factor != 1? Unfortunately we don’t have a Win7 machine to test this on but could you try changing the getWindowScaleFactor() method in juce_OpenGL_win32.h (here) to this:

double getWindowScaleFactor (const Rectangle<int>& screenBounds)
{
    if (nativeWindow != nullptr && shouldScaleGLWindow (nativeWindow->getNativeHandle()))
        return Desktop::getInstance().getDisplays().findDisplayForRect (screenBounds).scale;

    return Desktop::getInstance().getGlobalScaleFactor();
}

and see if that fixes the issue?


#17

I’m sorry to be annoying but I have a hard time accepting you guys don’t at least have a VM for each recent OS to test with!


#18

We do have one, but it’s a spectacular pain to use - it’s tied up in our CI system and is extremely slow to use interactively. If it’s possible to debug vicariously via the forum that will be a more efficient use of time.


#19

Yes, that fixed the issue on Windows 7. Thank you! Is that something you plan on rolling back into the standard source?


#20

OK, great. I’ll get it pushed to the develop branch now, it’ll make its way onto master and the website downloads when we do a point release.