I just wanted to report that recompiling my plugin on Windows using 3.7.9 result in an empty window (when launching the editor) and a hang when using the VST3 Plugin Test Host.
I am not sure what the problem is just yet, but I wanted to report in case somebody has seen this issue before and/or to be cautious if you want to upgrade.
Is this still an issue? Did you found out the reason?
Unfortunately not yet, but I have lacked the time to really dig deep.
I think for my next step, it makes more sense to generate a plugin with the generator provided with the SDK and check if I have the same result.
Hopefully I will be able to do that soon.
I confirm that generating a brand new plugin with the VST 3.7.9 generator then building it does not reproduces the issue.
So now I need to figure out what has changed (most likely in VSTGUI) to make my code fail. Note that it works fine on macOS…
I am definitely noticing something very odd. When using editorhost:
If the window is bigger than a certain threshold:
If the window is smaller:
Note that I cannot reproduce this specific behavior with the VST3PluginTestHost because the plugin hangs the UI entirely so I cannot right click to open the editor…
I was able to narrow down and reproduce the problem.
Here is the code that makes the UI fail
void draw(CDrawContext *context) override
{
context->setFillColor(kRedCColor);
auto viewSize = getViewSize();
PointList triangle{};
triangle.emplace_back(viewSize.left, viewSize.bottom);
triangle.emplace_back(viewSize.right, viewSize.bottom);
triangle.emplace_back((viewSize.left + viewSize.right) / 2.0, viewSize.top);
context->drawPolygon(triangle, kDrawFilled); // this call makes it fail (if you comment this line, it works...)
setDirty(false);
}
Here is the full source code for “myview” that I added to a freshly generated blank plugin generated with the VST3 Generator that comes with the SDK
myview.zip (854 Bytes)
As soon as you start dragging “My View 379” in the editor, you get this abort/error message.
Do you want me to create an issue on the vstgui github project?
Note: in the previous post, the reason why reducing the size of the window would make a difference is because the control that is triggering this issue ends up being not visible anymore, hence not rendered, hence the problem disappear…
Thanks, I will try to reproduce this issue later today.
Not needed. I pushed fixes to the master repository of vstgui for this issue a moment ago.
I am glad you were able to reproduce the issue and fix it. What does that mean for SDK 3.7.9? In this state, it is broken for Windows. Are you going to release an update for the SDK? How are you going to handle it?
It’s a bug not anyone is affected. You need to render a polygon to trigger it. No view or control shipped with the SDK uses it so I don’t think an update is needed. People can update vstgui to the latest GitHub version if they are affected.
I would argue that SDK 3.7.9 contains a breaking bug. The fact that the bug does not impact any widgets rendered by the SDK is irrelevant. Any user using polygon (which is not an obscure feature) will be affected. The fact that VSTGUI can be updated “separately” to fix the bug is not very user friendly.
If you don’t want to release a fixed SDK, I would suggest, at the very minimum, to add a very big disclaimer in the release notes so that other user don’t waste hours trying to figure out why their code is suddenly not working…
should already use cached graphics path objects instead as it is more performant on modern graphics systems.
The version of VSTGUI was already released a few month ago and no one has reported the issue yet, so it is not widespread in use at all. I will change the SDK on GitHub so that anyone cloning the SDK afterwards will get the fix.
This could help: Here a tutorial for using a different VSTGUI version: Switching to another VSTGUI submodule or branch - VST 3 Developer Portal (steinbergmedia.github.io)