Custom workspace = slow HISE

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

https://docs.juce.com/master/classSharedResourcePointer.html#a37f5da91a94a3f34a8d467a11b1db2ae

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.