VST wrapper, unwise size?


#1

I notice that the Juce VST wrapper determines the size of the GUI by creating the entire GUI and reading the size of the Component. I find that being a bit of an overkill; especially when you would load a lot of graphics during setup. It would be a lot of memory allocation for fetching just two integers: width & height, two numbers you know as a developer anyway.

The final creation of the GUI begins by deleting the editor that was created just millseconds ago.

I suggest this unnecessary procedure should at the very least be proceeded by some sort of GetGuiSize() call.

Thanks!


#2

Julian, is this something you could consider looking at? I can of course change it myself, but I hate to end up in a situation where I have to patch libraries every time I update it.

Thanks - Michael


#3

I actually quite like the way it works. The way I see it, your plugin should not have any direct knowledge about the GUI, except to be able to return a pointer to it. To make the plugin aware of what size the GUI will be when you create it at some point in the future feels like bad encapsulation.

Plus: if your GUI runs slowly in the current system, then it will also run slowly when you create multiple instances of the plugin with their GUIs open, and will be slow when you close and re-open the GUI. Any time-intensive tasks that it needs to run should be cached and shared between instances to minimise all of these delays, and if you’ve done that properly, then re-opening it a couple of times should not be a problem at all.


#4

[quote=“jules”]I actually quite like the way it works. The way I see it, your plugin should not have any direct knowledge about the GUI, except to be able to return a pointer to it. To make the plugin aware of what size the GUI will be when you create it at some point in the future feels like bad encapsulation.

Plus: if your GUI runs slowly in the current system, then it will also run slowly when you create multiple instances of the plugin with their GUIs open, and will be slow when you close and re-open the GUI. Any time-intensive tasks that it needs to run should be cached and shared between instances to minimise all of these delays, and if you’ve done that properly, then re-opening it a couple of times should not be a problem at all.[/quote]
Could we not at least keep the instance of the gui already created, instead of recreating it 1 ms later?

Besides, there are many instances where you would always know the exact measurements. A quick test to check if we know for sure is a cheap way to bypass a lot of unnecessary load.


#5

Putting the GUI size in the plugin just feels like a total hack to me!

The overhead of creating and deleting an off-screen component object should be so small that it’s not noticeable. If your components take so long to create that it’s causing a problem, then you need to improve your caching. Even if the wrapper cached the first component for you and re-used it, that won’t help with the delay that must be happening each time a new component gets created afterwards.


#6

Now, where is the GUI spawned from in the first place? AudioProcessor creates the GUI. Of course it would know the size of it, both before, during and after.

Caching aside, I feel it’s silly throw away an entire GUI when all you’d want is 2 integers.

But I wont press this further. I see you have a firm opinion.


#7

I do understand your point, but I just can’t imagine any situation where this would be a better solution than simply writing a GUI that works more efficiently.