Custom workspace = slow HISE

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:

https://github.com/christophhart/HISE/blob/65fbb2e8cdbb2e365bfbb38186be259b8735f2c9/hi_tools/Macros.h#L179

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

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

Custom workspace = slow HISE

12

2.0k

10.9k

94.9k