GlobalScaleFactor bug?

If I add this line in the first line of the PluginEditor’s constructor…

Desktop::getInstance().setGlobalScaleFactor(1.31511f);

… then I set the PluginEditor’s size later in the constructor, then somehow the parent of the editor will get an x;y offset of a few pixels leaving unoccupied space in the top and left of the Editor.

It seems reSetting the size of the Editor later, whenever it is already added to a parent will realign the positions and removes the gaps… Obviously setting the size again wouldn’t do the trick so setting it to 0;0 then set it to the original size will fix the alignment (but not in the constructor as then it doesn’t have a parent yet).

It seems not every scalefactor causes this, so maybe it’s some kind of rounding problem:

  • I can’t repro this if the scalefactor is <= 1.0f
  • depending on the actual size of the plugin some scale factors introduce the offset, some not.

I just creted a brand new JUCE project and did nothing but added the next line before the setSize(400,400):

juce::Desktop::getInstance().setGlobalScaleFactor(1.31511f);

this is how Ableton shows the window:

@t0m do you think this is intended behavior or a bug? So should we find a workaround or it can be addressed inside JUCE?

1 Like

Hi, I’ve also encountered this bug both with VST2 & VST3 formats. Tested in Reaper and Ableton on Windows, have not yet tested on MacOS.

1 Like

Not that this shouldn’t work as described, but the way I’ve always done this is activate the resizer, wrap your editor all in a single “MainView” component or whatever, and apply a transform to that when size changes.

1 Like

Yeah, as far as I remember that was the classic way to do it, but now JUCE recommends to use the GlobalScaleFactor… I could be wrong though. And yes the transform probably can cover this issue as a workaround, just wanted to know if it’s me doing something silly or not.

Thanks for reporting. The issue was a bit deeper than a rounding error, but the rounding error was flagging up the root cause. With certain global scale factors the integer top-left position for the plug-in window was changing slightly, causing the SWP_NOMOVE flag to be unset it the call to SetWindowPos. This exposed a problem with how we were calculating the client coordinates for HWNDs with a parent which has been addressed in b5a06b0. I’ve tested this in Live 10 and 11 as well as a few other hosts and it seems to fix the issue but please let us know if it hasn’t fixed things for you.

2 Likes

Thank you Ed for the quick fix! It works nice for us now!