Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
VincyZed opened this issue Mar 21, 2020 · 18 comments
Closed

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

VincyZed opened this issue Mar 21, 2020 · 18 comments
Labels
Skinning Engine Issues related to Surge's skin engine

Comments

@VincyZed
Copy link
Collaborator

VincyZed commented Mar 21, 2020 •
edited
Loading

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.
@VincyZed VincyZed added the Skinning Engine Issues related to Surge's skin engine label Mar 21, 2020
@baconpaul
Copy link
Collaborator

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

baconpaul added a commit to baconpaul/surge that referenced this issue Mar 21, 2020
@baconpaul
Leak checkers; and clean up offscreen caches
704d171 
In surge-synthesizer#1647 we had a report that the skin engine seemed to increase
load time as the run went on, probably due to a leak. This change
adds some leak checkers I can use, and also closes one leak
in the CScalableBitmap offscreenCache which was never forgotten.

Addresses surge-synthesizer#1647
@baconpaul baconpaul mentioned this issue Mar 21, 2020
Merged
baconpaul added a commit to baconpaul/surge that referenced this issue Mar 21, 2020
@baconpaul
Leak checkers; and clean up offscreen caches
312cbe3 
In surge-synthesizer#1647 we had a report that the skin engine seemed to increase
load time as the run went on, probably due to a leak. This change
adds some leak checkers I can use, and also closes one leak
in the CScalableBitmap offscreenCache which was never forgotten.

Addresses surge-synthesizer#1647
@baconpaul
Copy link
Collaborator

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).

baconpaul added a commit that referenced this issue Mar 21, 2020
@baconpaul
Leak checkers; and clean up offscreen caches (#1651)
135d02f 
In #1647 we had a report that the skin engine seemed to increase
load time as the run went on, probably due to a leak. This change
adds some leak checkers I can use, and also closes one leak
in the CScalableBitmap offscreenCache which was never forgotten.

Addresses #1647
@VincyZed
Copy link
Collaborator Author

Sounds good, will test later.

@VincyZed
Copy link
Collaborator Author

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

@baconpaul
Copy link
Collaborator

Ok thanks

@baconpaul
Copy link
Collaborator

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!

baconpaul added a commit to baconpaul/surge that referenced this issue Mar 23, 2020
@baconpaul
Fix 3 memory issues in the skin parser
89746b3 
1. (Major) - leaked the SVG parse tree all the time
2. (Medium) - leaked a reference to a Gradient when drawing
3. (Small) - didn't forget images when reloading by path, although that
   API was unused

Addresses surge-synthesizer#1647
@baconpaul baconpaul mentioned this issue Mar 23, 2020
Merged
baconpaul added a commit that referenced this issue Mar 23, 2020
@baconpaul
Fix 3 memory issues in the skin parser (#1665)
5edda34 
1. (Major) - leaked the SVG parse tree all the time
2. (Medium) - leaked a reference to a Gradient when drawing
3. (Small) - didn't forget images when reloading by path, although that
   API was unused

Addresses #1647
@VincyZed
Copy link
Collaborator Author

Still happens unfortunately.. :/

@baconpaul
Copy link
Collaborator

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
Copy link
Collaborator

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

@VincyZed
Copy link
Collaborator Author

VincyZed commented Mar 23, 2020 •
edited
Loading

Yes I confirm, running the latest nightly:

image

I will test in Reaper on my end as well.

@baconpaul
Copy link
Collaborator

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
Copy link
Collaborator Author

VincyZed commented Mar 23, 2020 •
edited
Loading

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
Copy link
Collaborator Author

VincyZed commented Mar 23, 2020 •
edited
Loading

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
Copy link
Collaborator

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
Copy link
Collaborator Author

VincyZed commented Apr 10, 2020 •
edited
Loading

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.

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

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

Send me all three sets of instrumentation

@VincyZed
Copy link
Collaborator Author

Results:

image

image

image

@baconpaul
Copy link
Collaborator

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
Copy link
Collaborator Author

Fixed in #1705 . Thanks a lot!

@bobobo199733 bobobo199733 mentioned this issue Mar 5, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Skinning Engine Issues related to Surge's skin engine
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mkruselj @baconpaul @VincyZed