Slow GUI construction on win 10


#1

My (vst plugin) UI is really slow to open on windows 10.

it’s like a few hundred of milliseconds in macOS or windows7 (running in parallels desktop), but is 10 times slower (a few seconds!) in windows 10 (on the same machine, in bootcamp).

I’m going to investigate, but thought it would perhaps ring a bell to someone?
Any idea what could be the cause of such a difference?


#2

Has this changed recently? It could be due to the Windows hiDPI support that was added to the develop branch a few weeks ago.


#3

the hiDPI support was not the culprit, but calls to Typeface::createSystemTypefaceFor()!

I had several widgets, each one with its own WidgetLookAndFeel instance with a couple of createSystemTypefaceFor() calls at construction:

struct WidgetLookAndFeel : public LookAndFeel_V3
{
   Font myGreatFont = Typeface::createSystemTypefaceFor (BinaryData::MyGreatFont_otf,
                                                         BinaryData::MyGreatFont_otfSize);
   Font myGreatFont2 = Typeface::createSystemTypefaceFor (BinaryData::MyGreatFont2_otf,
                                                          BinaryData::MyGreatFont2_otfSize);
};

I did not looked into it any further, I just improved my lnf handling, and put my fonts in a SharedRessourcePointer.
I’m still curious as why there’s such a big difference though. Are the fonts cached somehow in osx and not in win10?


#5

I had the same issue using custom typefaces. I solved by removing the unused characters with a 3rd party app.


#6

Funny, just stumbling over the same issue here. Even with a SharedResourcePointer, when I’m using three custom fonts, it takes a few seconds to load a plugin UI on Windows 10 (on a usually fast machine). On first glance I couldn’t see anything that could be optimized in the relevant JUCE code though…


#7

I think we’ve seen this too, and IIRC it’s just something dumb in the Windows font code where if you give it a typeface to load from memory, it uses some other code-path which goes incredibly slowly compared to loading it from a file. I suspect that maybe it attempts to parse and cache every glyph up-front rather than loading the glyphs lazily, and if you give it a big unicode font, that’s a lot of glyphs to load. A workaround might be to try stripping down your font to include only the glyphs you need, but I don’t think there’s anything we could do to change what Windows does internally


#8

I’ve done some more profiling, and the time is spent in createKerningPairs(…) in juce_win32_Fonts.cpp, where there’s a loop over a number of kerning pairs, and that number is about 18000 for the fonts that I’m loading. I’m really no expert in the finer details of fonts and kerning, so I can’t judge whether that would be something that could be optimized.


#9

Ah, that’s interesting - sounds like a different thing to what I was talking about, and yes, a much better target for optimisation, maybe with some local caching of the widths.


#10

This commit should make a big difference - would be interested to know if it helps in your case:


#11

Thanks for the quick fix! That’s much better now… great!