Custom workspace = slow HISE
-
New empty project here, 8 - 10 seconds to open. Maybe a GNU/Linux only issue?
-
I just tested on Windows and no problem there so I think it's specific to my OS and possibly to my general setup. I'll try on my other GNU/Linux system.
-
Definitely seems to be OS specific, I just tested on Linux Mint and had the same issue as my main Debian system.
-
Just tested on MacOS, works fine...
-
Try compiling the plugin version of HISE and then load it in a DAW and close reopen the window. If the lag is also happening there you know it's something related to the UI.
-
@Christoph-Hart Good thinking, I'll do that now
-
The plugin version doesn't seem to read from the same editorData file as the standalone version. Each time I open it it's reset to the default layout, even if I make changes to the layout in the plugin.
-
@Christoph-Hart I've narrowed it down. When I remove the API browser from my custom workspace everything works normally.
-
I'm digging up this thread again. I posted another thread recently where I mentioned HISE was laggy and I thought it might be down to Alder Lakes E/P cores. But I disabled all the P cores and it didn't make a difference.
So then I started wondering if it was the issue in this thread and it was caused by the API browser now being present in the sidebar. So I commented out the source code where that API browser is added, and bullseye, HISE opens instantly. It also closes instantly now too, I never noticed that was lagging also.
So @Christoph-Hart when you have a moment, please see if you can find out why the presence of the API browser causes HISE be super laggy on Linux.
-
I've looked into this further and the issue is related to the help text generation. If I comment out this line, HISE loads up quickly (but obviously I get no help text).
Could this data be cached so it doesn't have to recreated everytime HISE is opened?
-
@Christoph-Hart Got any ideas about this?
-
@d-healey Hmm, this is already "cached" in the sense that it just parses a compressed value tree containing the docs and creates a C++ object containing the formatting which shouldn't take too long.
Can you investigate further? Maybe it's time for you to learn how to use a profiler to find hotspots - this should give you an exact call stack of the heaviest calls including where it spends the most time so we can pinpoint it down to the font hinting algorithm (my guess here). I think the main one in Linux is valgrind but I've never used it and I can imagine there is some Linux-style extra nerd layer applied to its workflow :)
EDIT: This looks like the tools I'm using on Windows / macOS and allows you to attach the profiler to a running HISE build, so it might be easier to get running.
-
@Christoph-Hart Thanks, I'll take a look and report back
-
Not exactly sure what I'm looking for but this stuff is eating some CPU when the API thingy isn't commented out.
-
@d-healey yup, looks font related (libfreetype seems to be the font library on Linux). Can you check the call stack for this call?
-
-
This post is deleted! -
Ah I think I finally worked out how to see some useful data. Does this help?
Digging further. It seems to be all these
help.commands inCodeEditorApiBase.cpp
-
@d-healey it looks like it‘s not caching the fonts so it destroys them everytime…
-
@Christoph-Hart Could this be related? https://forum.juce.com/t/slow-startup-due-to-font-enumeration/6864
