Custom workspace = slow HISE

[d.healey]

@Christoph-Hart Thanks, I'll take a look and report back

[d.healey]

Not exactly sure what I'm looking for but this stuff is eating some CPU when the API thingy isn't commented out.

[Christoph Hart]

@d-healey yup, looks font related (libfreetype seems to be the font library on Linux). Can you check the call stack for this call?

[d.healey]

[d.healey]

This post is deleted!

[d.healey]

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 in CodeEditorApiBase.cpp

[Christoph Hart]

@d-healey it looks like it‘s not caching the fonts so it destroys them everytime…

[d.healey]

@Christoph-Hart Could this be related? https://forum.juce.com/t/slow-startup-due-to-font-enumeration/6864

[Christoph Hart]

@d-healey I've pushed a possible fix that might keep the fonts alive on Linux and avoid the reconstruction of the font every time it's used), but I can't test it and it might be possible that this doesn't affect anything, so please check if it helps.

[d.healey]

@Christoph-Hart Thanks. I'll give it a try now

[d.healey]

@Christoph-Hart Doesn't appear to have helped unfortunately. Just to confirm that it isn't something unique to my system I also tested in a virtual machine and it's the same.

[Christoph Hart]

Can you add the destructor to the LinuxFontHandler::Instance() class, then set a breakpoint in its body (at the bogus line) and check when it's called? It should stay alive during the entire lifetime of the HISE application:

HISE/hi_tools/Macros.h at 65fbb2e8cdbb2e365bfbb38186be259b8735f2c9 · christophhart/HISE

The open source framework for sample based instruments - HISE/hi_tools/Macros.h at 65fbb2e8cdbb2e365bfbb38186be259b8735f2c9 · christophhart/HISE

GitHub (github.com)

    ~Instance()
    {
        int x = 5;
    }

[d.healey]

@Christoph-Hart I'll give it a go after lunch and report back.

[d.healey]

The destructor is triggered every time GLOBAL_BOLD_FONT() is called.

[d.healey]

I tried replacing the defines with this, to cut out the extra class stuff:

#define GLOBAL_FONT() (Font(Typeface::createSystemTypefaceFor(HiBinaryData::FrontendBinaryData::oxygen_bold_ttf, HiBinaryData::FrontendBinaryData::oxygen_bold_ttfSize)).withHeight(13.0f))
#define GLOBAL_BOLD_FONT() (Font(Typeface::createSystemTypefaceFor(HiBinaryData::FrontendBinaryData::oxygen_regular_ttf, HiBinaryData::FrontendBinaryData::oxygen_regular_ttfSize)).withHeight(14.0f))
#define GLOBAL_MONOSPACE_FONT() (Font(Typeface::createSystemTypefaceFor(HiBinaryData::FrontendBinaryData::SourceCodeProRegular_otf, HiBinaryData::FrontendBinaryData::SourceCodeProRegular_otfSize)).withHeight(14.0f))
#define GLOBAL_BOLD_MONOSPACE_FONT() (Font(Typeface::createSystemTypefaceFor(HiBinaryData::FrontendBinaryData::SourceCodeProBold_otf, HiBinaryData::FrontendBinaryData::SourceCodeProBold_otfSize)).withHeight(14.0f))

And surprisingly it made a big improvement. I don't think it's as fast as on Windows/MacOS though. And all the fonts in the GUI have changed, so I probably broke something :p

Scriptnode also isn't lagging like crazy now, so I think that issue was related.

And HISE isn't crashing as much when switching between big projects! How I have waited for this day.

[d.healey]

@Christoph-Hart Any more suggestions for me to try?

[Christoph Hart]

@d-healey try again with the latest build...

[d.healey]

@Christoph-Hart No improvement unfortunately. But wouldn't you have to make some change in Macros.h too since the GLOBAL_FONT defines are still calling LinuxFontHandler::Instance()...?

[Christoph Hart]

@d-healey Yeah my hope was that if you construct one instance that is alive during the entire lifetime of the app that it will keep alive the shared data object that holds the fonts. See here:

JUCE: SharedResourcePointer< SharedObjectType > Class Template Reference

(docs.juce.com)

So the solution is definitely keeping this thing alive. On the other hand it's so long time ago that I've implemented the custom Linux solution that I forgot why it's there in the first place (a comment would be nice here). So maybe we have to think about an entirely different approach and the performance impact that it has on Linux should definitely be addressed. Maybe I need to dust off my linux distro and give it a shot as this requires some advanced debugging.

[d.healey]

@Christoph-Hart You should join us in Proxmox land where every OS is at your fingertips.