vst2/vst3 GUI (cairo) offset under windows (branch: pugl-update-v4)
Closed this issue · 18 comments
While the pugl-update-v4 branch seems to mostly fix cairo GUI issues under macos, it introduce a new issue for cairo based GUI's under windows.
I checked that vst3 plugin GUI's running in flstudio works as expected when build against the main or the development branch. but appears as blank (black) window when build against the pugl-update-v4 branch. In this case it looks as if the plugin GUI have a offset of it's own size width and height and becomes visible when the UI was enlarged. True, with this offset in the window one could only see a part of the plugin GUI.
Note, that the stand-alone GUI's seems to not suffer from this issue. I've checked that issue for vst2 and vst3 based plugins.
This issue was reported to me here:
brummer10/ToneTwistPlugs#2
and after testing I could confirm it.
There seems to be as well a issue left within Reaper under macos, but that I can't test.
There are a lot of more GUI issues with the update-pugl-v4 branch.
So I switched back to the development branch and cherry picked the macos pugl patch which I apply now on build.
please dont, the cairo high-dpi stuff is broken without the new branch.
are you in a rush to release? this is better done carefully..
I see, now I remember why I've put setGeometryConstraints() to true before switch to pugl-update.
For now, setting automaticallyScaleAndSetAsMinimumSize to false in UI initialisation fixed that issue, only the GUI could now resized like gum (which is not a issue).
Well, I've released already
https://www.kvraudio.com/product/tonetwistplugs-by-brummer
because I've only a few day's left free before my working season starts again.
ok I understand. it is good to have your plugins anyhow, I can test and verify things with the new pugl until everything works.
btw if you can only have 1 macos download, make that the universal build. the intel one is deprecated, as any new apple hw is not intel based anymore.
I can test and verify things with the new pugl until everything works.
That will be very welcome.
btw. I just found your ResizeHandle.hpp file and implemented it to allow scalling for vst2 plugs. Seems to work nicely here. I rewrote it to use cairo instead opengl to match my suite. I may push a update release tomorrow and fix then as well the download link for macos. Seems to be any way broken for macos:
brummer10/ToneTwistPlugs#2 (comment)
the resize handle uses internal dpf methods, so it should work with cairo as-is. if not I would consider it a bug.
sure it works. I just ported the drawing to cairo instead opengl.
what I mean is that it already uses cairo, through https://github.com/DISTRHO/DPF/blob/main/dgl/src/Cairo.cpp#L60
it is why it is on the "generic" folder in dpf-widgets, because it can be used for both opengl and cairo
what is the generic folder? I found it in the examples and take it from there. If it is part of dpf I'll use it as it is, but were is it then?
Ah, dpf-widgets, so a extern repository
what I mean is that it already uses cairo, through https://github.com/DISTRHO/DPF/blob/main/dgl/src/Cairo.cpp#L60
ha, hence why it looks so similar.
forgot to say, I implemented as well support for keepAspectRatio, that should work as well with the ResizeHandle as it is.
Edit: Yes, could use it as it is, just added the keepAspectRatio support.
this was indeed a pugl related breakage, as it tries to center windows by default even if they are embed, which dpf was not expecting.
now dpf forces 0,0 as the offset for embed windows, seems to work here, please confirm.
EDIT: obviously after updating dpf in the new branch again.
This looks good. I tested vst2/vst3 in Reaper and renoise and it works as expected. Nice.
I'll push out a update release for ToneTwistPlugs very soon.
Now, I've one silly question.
When I use setGeometryConstraints(143, 200, true, true);
instead UI(285, 400, true)
the (internal) effect is the same, I mean for keepAspectRatio and automaticallyScale.
Only differ in that I could reduce the size below the initial size. Isn't that?
yes. the UI constructor parameter just calls things for you automatically so you dont have to deal with that later.
but in the cases where the default size is not the same as the minimum size, you should not use the UI parameter but call "setSize + setGeometryConstraints" manually (with special care to call setSize first in case scale factor is not 1)
do your plugin guis even need to be resizable? there is less complications for hosts and event handling if UI is of fixed size, scaling automatically as needed.
They don't really need to be, it's more a personal preference.
If the automatic scaling works ( I guess it does that on init) even when the UI is resizeable by the user I'll prefer to make them resizeable.
then the simplest is to use the UI argument there. then dpf needs to take care of everything else. and any bugs would be on dpf side to fix.
Yep, that's what I've done now. Latest release v0.6 is out and all plugs using the UI argument (UI(285, 400, true)) and no more setGeometryConstraints().
When all settled and I get my next work free season I'll focus on create the necessary widgets for moving guitarix to dpf.
ok cool. I am closing this ticket then. still want to do a few more tests before calling this new branch good for use, so let me know if any other oddities or bugs appear.