Surge: Skinning Engine: GUI takes longer to load the more you open the plugin

[VincyZed]

Description:
The more you open and close the GUI (let's say spam open-close), the longer it will eventually take for Surge's GUI to load when you open it.

Version:
Latest nightly, VST3 x64

To Reproduce
The first time it loads, on my machine it takes probably less than 1/4 of second to open. After spamming open-close for 30 seconds, each time I open it back, I get FL to hang for more than 3 seconds before it finally appears.

Expected behavior
Load times should be quick and consistent, like they used to be before the big skin update

Desktop (please complete the following information):

• OS: Windows 10 x64
• Host: FL Studio 20.6.2 x64

Additional context
Some noteworthy behaviors:

1. I am using the dark skin. Changing skin back to default is very quick. But changing it back to dark takes a long time again.
2. Opening a second instance of the plugin (it remembers that I have dark theme) takes a long time as well.
3. Removing all instances of Surge in a FL project and loading a new one back almost restores it back to its normal loading speed. (still hangs a bit more than usual)
4. Closing and re-opening FL completely restores it back to its normal loading speed.
5. This also happens when using the normal light skin, but it's less pronounced.
6. This does not happen with release 1.6.6.
7. While hanging, one CPU thread is being maxed out.
8. Playback continues in the background as normal. Only FL's GUI freezes completely.

[baconpaul]

I am 100% sure I have a memory or resource leak causing this. Thanks. Will look.

[baconpaul]

OK I found one leak which would be irritating on windows for sure. In theory it shouldn't be that bad in the VST3 but since it leaks screen handles with have GDI handles it would be pretty grim if it went on long enough.

Just letting the PR build. Check a nightly in 45 minutes or so. I'm going to leave this open since there may be other things (and I did memory debugging on mac rather than repro it on windows for now).

[VincyZed]

Sounds good, will test later.

[VincyZed]

So I did test and have not seen any difference so far.. The problem still occurs unfortunately.

[baconpaul]

Ok thanks

[baconpaul]

So running the VST3 in Reaper 64 bit on win 10 it seems I leak about 10-15 mb (!!) on every window open and close.

So there's something to debug for sure!

[VincyZed]

Still happens unfortunately.. :/

[baconpaul]

Can you just be sure that you are running the absolute latest version? The about screen shows hash 5edda34

I’m surprised this didn’t fix it; it was a big leak! I’m at a bit of a loss since I don’t know windows leak debugging tools nearly as well as I do mac or linux so lets just quadruple confirm the version thing first if thats OK?

[mkruselj]

I don't think I can confirm the memory leak in Reaper. Might be FL being dumb a bit.

[VincyZed]

Yes I confirm, running the latest nightly:

I will test in Reaper on my end as well.

[baconpaul]

Hmm. So mac used to leak and doesn’t; evil reports reaper windows doesn’t. I wonder what’s up

@VincyZed also can you open the task manager and look at memory for FL as you open and close? Does it grow every time?

FL may be interacting with the VST3 differently than Reaper too so may not be calling all my close paths, and I could easily have a bug like that.

[VincyZed]

I just tested in Reaper and it also does the same thing! So not just an FL problem. Will check for the memory thing.

[VincyZed]

So FL's memory usage seems to increase from about 500 KB to 1MB each time I open the plugin. When closing it, memory usage goes down a bit (obviously), but memory when Surge is closed also increased compared to the first time loading Surge.

[baconpaul]

Memory sort of doesn't deallocate cleanly so the residual increase makes sense.

But seems like something is still leaking for you. Hmm. Wonder what it is! I'll test some more and keep chipping away.

[VincyZed]

From Paul over on Slack:

1. Open a fresh session in your DAW and open a surge. Right when you open it do “menu/dev/show UI Instrumentation” and screenshot or save that.

1. Then open and close the UI exactly once and do the same

2. Then open and close the UI 10 times and do the same

Send me all three sets of instrumentation

[VincyZed]

Results:

1.

2.

3.

[baconpaul]

Thank you! I’ll take a look this weekend and compare with macos
The ::READ vs ::GET was what I was hoping would solve the problem but ... ahh well.

[VincyZed]

Fixed in #1705 . Thanks a lot!