Delaying creation of (some of) the GUI until it gets created for real

Audio Plugins
1

Given that hosts can create and delete your editor several times before it actually opens, is there any good way to block the initialization and creation of the guts of the GUI until it actually wants to be created for real?

I’ve though about using Timer::callAfterDelay() or some other delayed mechanism, but I wonder if anyone else is doing this?

I have a very complicated plugin with a whole-lot-o-gui, and it takes a long time to Create it and Destroy it twice before it opens the third time (which is what the JUCE AudioPluginHost does when you open the editor…)

2

You could maybe wait for the editor to be added to a parent window & made visible. I probably wouldn’t bother though, I think your contract with the host is to just create the editor when AudioProcessor::createEditor() is called, and if the host creates multiple editors inefficiently, that’s on the host.

3

Profile the UI code and optimize the heck out of it. A lot of times this can be done by properly baking resources instead of just using them ‘out of the box’ as received by the designer. See also, converting heavy bitmap graphics elements to SVG … this can prove fruitful in terms of reducing the heap allocations/deallocs…

For profiling, I can highly recommend the use of @sudara’s excellent melatonin_perfetto module:

4

I’m afraid that’s not the problem. I’m already using SVG for everything. The problem is there are multiple tabbed components, each with multiple pages of 30 - 50 parameters (sliders, comboboxes), that all get created and destroyed. The editor takes like 5 seconds to open up (and it seems worse with JUCE 8, although I have no concrete measurements.)

5

Lazy loading is your friend. Create child components only when the tab / sub view is made visible.

2 Likes
6

I guess you mean using something like std:unique_ptr for all components, instead of declaring them inside the parent class component?

7

Maybe you could override parentHierarchyChanged in your editor and create your tabbed components from that callback once your editor window has a component peer and is actually visible.

Matt

1 Like
8

That’s a very good suggestion. I have overridden parentHierarchyChanged() and can indeed see the moment when a peer has been added, when it is visible (but not yet showing) - and this only happens once when the editor is created - and not for each time the editor is falsely created/destroyed. Will attempt to look into this.

2 Likes
9

Is it the case that these creations/destructions are ‘false’, or intended - by design of the DAW? As I understand it, plugins can be instantiated by hosts a number of times before being presented to the user - first to validate the plugin, then to get the plugin instance properly associated with the DAW process, and finally once the DAW has loaded a project and relevant parameters are communicated to the plugin …

10

Semantics, sorry. It’s entirely valid/intended as far as the DAW is concerned. But it still is the creation and destruction of a whole bunch of stuff that is unnecessary to be created if it’s not going to be shown/used.

I’m sure that for most simple plugins with a one page GUI, this is not an issue. I have probably 40 tabs of parameters, however, and a large chunk of screen real estate.

11

Roger that - would be quite interested in the approaches you take to resolve this situation when you get it under control, especially the lazy-loading suggestion …