Allow configuring diag font path at build time

[oscarwcl]

This allows for better integration with distros that put the system font in a different directory.

As suggested in #1308 (comment).

The equivalent of the old -DUSE_SYSTEM_DIAG_FONT=ON option is now -DDIAG_FONT_PATH=/usr/share/fonts/truetype/liberation/LiberationMono-Regular.ttf

[nerijus]

typo - distribtued, should be distributed

[dimitry-ishenko]

I am a bit late to the scene, but what if the font path is not known at build-time? Or, what if it's not the same on the build machine compared to the target machine?...

IMHO the options should be: (1) bundle the font in a specific location (eg, next to the main executable) and (2) use system facilities to locate the font (eg, fontconfig on Linux).

[Julusian]

The aim of this is to be friendly for distributing as a debian/arch/whatever package. In which case it can be reasonably assumed that the font will be found at a predictable path.

Yeah I didn't think about using a system library to locate it. But I probably wouldn't have done it anyway, because it seems like quite an effort for what it is.
I'll accept a pr that uses fontconfig for this, as long as it isn't too big of a heap of code to do so

[dimitry-ishenko]

I've looked at the fontconfig API and it's a bit of a mess... One lazy way of doing it would be something like this:

std::string font_path;
auto pipe = popen("fc-match --format=%{file} LiberationMono-Regular.ttf", "r");
char buf[128];
while (fgets(buf, sizeof(buf), pipe)) font_path += buf;

It's marginally less hacky than hard-coding the path, but if you are cool with it, I can spin off a PR shortly.

[dimitry-ishenko]

@Julusian see #1559

One thing I saw that I didn't like was that the get_default_font() function contains a static variable (DEFAULT_FONT). While it has a nice feature of being initialized on first use, it does involve a hidden lock (since C++11) and a check on each invocation.

In this particular case it would be cheaper to create a class static variable (inside graph) and initialize it once. There are also a few other statics inside graph::render() with the same problem. I believe this function gets called multiple times per second, so there could be some performance hit.

[dimitry-ishenko]

To elaborate on using static local variables, see this: https://godbolt.org/z/oEd7GMseT. Every time the function is called, it has to acquire and release the lock.

[dimitry-ishenko]

@Julusian here are test results, which show that using global static variables gives ~15% speed improvement on Coliru.

Single-threaded: https://coliru.stacked-crooked.com/a/ba4ab9ed90d28352

Static  local: 5824ms
Static global: 4856ms (-16.62%)

Multi-threaded: https://coliru.stacked-crooked.com/a/ac8424b20ed46f5a

Static  local: 5573ms
Static global: 4738ms (-14.98%)

On my local machine I get even more dramatic results:

Single-threaded:

Static  local: 5983ms
Static global: 3992ms (-33.28%)

Multi-threaded:

Static  local: 3697ms
Static global: 2064ms (-44.17%)