Modern Unix GUIs now need to talk to at least one C library

May 5, 2018

I've written before about whether the C runtime and library are a legitimate part of the Unix API. The question matters because some languages want to be as self contained as possible on Unix (Go is one example), and so they don't want to have to use anything written in C if at all possible. However, I recently realized that regardless of the answer to this question, it's essentially impossible to do a good quality, modern Unix GUI without using at least one C library.

This isn't because you need to use a toolkit like Gtk+ or QT, or that you need a C library in order to, for example, speak the X protocol (or Wayland's protocol). You can write a new toolkit if you need to and people have already reimplemented the X protocol in pure non-C languages. Instead the minimal problem is fonts.

Modern fonts are selected and especially rendered in your client, and they're all TrueType fonts. Doing a high quality job of rendering TrueType fonts is extremely complicated, which is why everyone uses the same library for this, namely FreeType. FreeType is written in C, so if you want to use it, you're going to be calling a C library (and it will call on some additional services from something like the C runtime, although apparently you can shim in your own versions of some parts of it).

(Selecting fonts is also a reasonably complicated job, especially if you want to have your fonts match with the rest of the system and be specified in the same way. That's another C library, fontconfig.)

There's no good way out from calling FreeType. Avoiding it requires either abandoning the good modern fonts that users want your UI to have, implementing your own TrueType renderer that works as well as FreeType (and updating it as FreeType improves), or translating FreeType's C code into your language (and then re-translating it every time a significant FreeType update comes out). The latter two are theoretically possible but not particularly practical; the first means that you don't really have a modern Unix GUI program.

(I don't know enough about Wayland to be sure, but it may make this situation worse by essentially requiring you to use Mesa in order to use OpenGL to get decent performance. With X, you can at least have the server do much of the drawing for you by sending X protocol operations; I believe that Wayland requires full client side rendering.)

The direct consequence of this is that there will never be a true pure Go GUI toolkit for Unix that you actually want to use. If the toolkit is one you want to use, it has to be calling FreeType somewhere and somehow; if it isn't calling FreeType, you don't want to use it.

(It's barely possible that the Rust people will be crazy enough to either write their own high-quality equivalent of FreeType or automatically translate its C code into Rust. I'm sure there are people who look at FreeType and want a version of it with guaranteed memory safety and parallel rendering and so on.)


Comments on this page:

By firesock at 2018-05-05 07:36:40:

The Rust people are crazy enough to have started, I believe:

https://github.com/google/font-rs

https://github.com/pcwalton/pathfinder

With Pathfinder getting some interest and momentum from the Servo side of things.

By skeeto at 2018-05-05 07:59:55:

The stb_truetype.h library demonstrates that proper TrueType rendering can be done in just over 4 kLOC of ANSI C. It may be a little slower and slightly lower quality (no hinting support) compared to FreeType, but I can't find any recent side-by-side comparisons. This is smaller than David M. Gay's dota.c (e.g. strtod()), which is currently about 6 kLOC, and every language needs one of these. So it doesn't seem so crazy for a language to implement its own TrueType rendering.

By cks at 2018-05-05 14:29:28:

My suspicion is that STB's TrueType rendering is not as good or as general as FreeType, because I don't think FreeType is written by bad programmers (if it was, I don't think it would be so widely adopted) and it's much bigger. Not as fast may also be a serious issue in some environments, since some GUI programs render quite a lot of text.

(It turns out that FreeType also renders a number of other types of fonts, which I'd forgotten, but just its TrueType support is fairly large. Some of that size is historical, eg, but not all of it.)

Written on 05 May 2018.
« Why you can't put zero bytes in Unix command line arguments
Firefox turns out to need some degree of 'autoplay' support »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sat May 5 00:13:25 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.