GlobalScaleFactor bug?

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


… 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):


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.


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