Custom workspace = slow HISE

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

[d.healey]

@Christoph-Hart Is this Linux font handler stuff needed?

I just replaced the calls with this and it's now as fast as on Windows and MacOS

static Typeface::Ptr oxygenBoldTypeFace = Typeface::createSystemTypefaceFor(HiBinaryData::FrontendBinaryData::LatoBold_ttf, HiBinaryData::FrontendBinaryData::LatoBold_ttfSize);
static Typeface::Ptr oxygenTypeFace = Typeface::createSystemTypefaceFor(HiBinaryData::FrontendBinaryData::LatoRegular_ttf, HiBinaryData::FrontendBinaryData::LatoRegular_ttfSize);
static Typeface::Ptr sourceCodeProTypeFace = Typeface::createSystemTypefaceFor(HiBinaryData::FrontendBinaryData::SourceCodeProRegular_otf, HiBinaryData::FrontendBinaryData::SourceCodeProRegular_otfSize);
static Typeface::Ptr sourceCodeProBoldTypeFace = Typeface::createSystemTypefaceFor(HiBinaryData::FrontendBinaryData::SourceCodeProBold_otf, HiBinaryData::FrontendBinaryData::SourceCodeProBold_otfSize);

#define GLOBAL_FONT() (Font(oxygenTypeFace).withHeight(13.0f))
#define GLOBAL_BOLD_FONT() (Font(oxygenBoldTypeFace).withHeight(14.0f))
#define GLOBAL_MONOSPACE_FONT() (Font(sourceCodeProTypeFace).withHeight(14.0f))
#define GLOBAL_BOLD_MONOSPACE_FONT() (Font(sourceCodeProBoldTypeFace).withHeight(14.0f))

[d.healey]

@Christoph-Hart I definitely think whatever I did in my last post fixed the problem. It's super fast on Linux now, I tested on my current system and a few year old Linux Mint release. I also tested a compiled project, no issues.

Any reason I shouldn't make a pull request?

[Christoph Hart]

@d-healey Yes, go for it, I forgot what that LinuxFontHandler stuff was about anyways...

[Christoph Hart]

@Christoph-Hart A quick search in the JUCE forum yielded this:

https://forum.juce.com/t/lookandfeel-custom-fonts-linux-leaks/53914

Apparently using static instances causes the memory leak detector to fire on Linux (probably why I was introducing the LinuxFontHandler stuff).

[d.healey]

@Christoph-Hart How can I detect if a leak is happening?

[d.healey]

@Christoph-Hart Two interesting things I noticed with my "fix". Debug builds of HISE give a segfault, and my compiled plugin crashes pluginval. I guess this is related to the leak problem.

However it's much more pleasant to work in HISE when I don't have this slow issue so I'm thinking a pre-processor definition is the way to go until a proper fix is possible.