[SOLVED] Messed up fonts and DirectWrite

Hi guys,
I have an issue about fonts rendering on Windows.

Same code as OSX, but I get it totally wrong and chopped. If I disable DirectWrite, then it renders as expected

The only problem is… the plugin Editor becomes terribly slow while opening (up to 8 seconds on an i7).

Any advice?

Thanks

Best to post some code that reproduces it.

When you say it’s slow to open, that really could be anything, so please profile it to make sure there’s not something silly happening in your own code before we take a look!

Thanks Jules.
I have the custom fonts embedded and declared in my LAF this way:

ptSans = Typeface::createSystemTypefaceFor(BinaryData::PTS55F_ttf, BinaryData::PTS55F_ttfSize);
ptSansBold = Typeface::createSystemTypefaceFor(BinaryData::PTS75F_ttf, BinaryData::PTS75F_ttfSize);

then, in either getComboBoxFont and getLabelFont I have that:

if(box.getName() == "modeMenu")
            return Font(ptSansBold.getTypefaceName(), 12, Font::bold);

same for labels using label.getName()

In the plugin Editor I just add them using addAndMakeVisible and setting the LAF to use.

You mean directwrite?

Yes, sorry… I meant DirectWrite

By the way, there is an unsolved threading issue when Direct Write is turned off, i posted some code to reproduce the problem some time ago Threading issue with Graphics::drawText (its not urgent, but just for the record. With Direct Write it works)

Thanks, but there are still too many unknowns here for us to help - if you have a chunk of self-contained code we could copy-paste into a project and run, then someone here could try it, but otherwise it could be a wild goose chase for us trying to reproduce the same thing…

Later I’ll set up a new test plugin to replicate the issue.

I’m also seeing this here.
I didn’t pay much attention to it so far.

This is Windows 10, Built with VS2015. USE_DIRECTWRITE is Default (which I see is defined as 1 by default).


(Notice the DEMU instead of DEMO)
Some elements don’t get this is.

Some init code that might be worth something:

juce::LookAndFeel::getDefaultLookAndFeel().setDefaultSansSerifTypefaceName ("Trebuchet MS");

The offended code is:

void SurferPrescaledUI::Background::paint (Graphics& g)
{
g.setColour (Colours::white);
g.setFont (30);
g.drawSingleLineText (“DEMO”, 650, 56);
g.drawSingleLineText (“VERSION”, 650, 80);
}

I need to do more tests (but I just wanted to chime-in as I guess this is helpful than nothing right now).
One note, the component that paints this isn’t the main window and it’s being scaled down on non-retina.

I noticed that looks like the font’s points to pixel conversion size is different on OSX and Windows.

ok… in the meanwhile I found why the editor is so slow while drawing… it’s the embedded font. if I comment both the lines where I create the system Typeface, the editor is built instantly… no lag.

Fixed. I removed the global Font variables I were using and created a static method where I return a static Typeface::Ptr with createSystemTypefaceFor.

static Typeface::Ptr getMyTypeface()
{
  static Typeface::Ptr myTypeface = Typeface::createSystemTypefaceFor(BinaryData::PTS75F_ttf, BinaryData::PTS75F_ttfSize);
  return myTypeface;
}

In the getComboboxFont and getLabelFont methods I now return:

return Font(getMyTypeface()).withPointHeight(12);

In this way the font height is consistent in both OSX and Windows and the drawing speed is fast as it has supposed to be.

Hope this will help anybody facing the same issue.

Cheers,
Luca

1 Like

Seems like a classic case for SharedResourcePointer:wink:

1 Like

I missed this kind of pointer. Thanks Daniel!

sorry for reviving an old/solved thread.
I have the same issue for some fonts, where DirectWrite comes up with a different height than win32 typemetrics, resulting in a different getHeightToPointsFactor().
To me it seems like DirectWrite comes up with a consistent (therefore right?) look compared to macOS

My only solution is to check which fonts behave like this and not use them. changing code only for some fonts feels weird to me. is there any better solution?