Infos zum GEOS TTF-Treiber

Anbei ein kleines Statusupdate zum TTF-Treiber.

Was ist in den letzten Monaten passiert?

Die vergangenen Monate standen ganz im Zeichen von Optimierungen, kleinen Refactorings und Korrekturen. Ziel war es die Stabilität, die Performance, den Speicherbedarf und auch die Binarysize des Treibers weiter zu verbessern.

Ein größeres Refactoring habe ich dabei schon länger vor mir her geschoben. Nun habe ich aber begonnen mich damit zu beschäftigen.

Worum geht es dabei?

Konkret geht es um den TTCache von FreeType. Für PC/GEOS haben wir im TTF-Treiber zwei eigene Cacheebenen implementiert. Eine davon ist nicht persistent, die andere persistent. Der TTCache von FreeType wird deshalb im Treiber nicht benötigt und auch nicht genutzt. Er belegt aber trotzdem unnötig Ressourcen.

Das Ziel des Refactorings ist es daher diesen TTCache aus dem Treiber auszubauen.

Wie so oft ist das Entfernen von Code aber nicht nur ein Entfernen von Code. Durch den Ausbau des TTCaches haben sich eine ganze Reihe weiterer Optimierungsmöglichkeiten ergeben. Diese möchte ich natürlich nicht ungenutzt lassen. Bis hier hat sich das auch schon deutlich gelohnt.

Ein paar Messwerte

Um das etwas greifbarer zu machen hier ein Vergleich mit dem Font Lister.

Gemessen habe ich auf meinem üblichen Testsetup: Intel i7 der 4. Generation unter Linux mit Basebox und 35000 Zyklen und nc target.

Treiber aus der aktuellen Alpha Version vom 15.05.26:

• Nimbus Sans: 316 ms
• Nimbus Mono: 300 ms
• Nimbus Roman: 350 ms

Treiber aus dem Branch ttf-driver-remove-ttcache:

• Nimbus Sans: 200 ms
• Nimbus Mono: 183 ms
• Nimbus Roman: 200 ms

Das ist natürlich nur ein einzelner Testfall und noch kein vollständiger Benchmark. Aber die Richtung ist schon recht erfreulich. Je nach Font liegt die Verbesserung hier grob bei 37% bis 43%.

Was ist noch passiert?

Im genannten Branch habe ich außerdem begonnen einige technische Schulden abzutragen. Ein Stichwort dazu ist Subbanding. Das ist eine der Stellen im Treiber, bei der schon länger klar war, dass sie irgendwann noch einmal etwas Aufmerksamkeit braucht.

Ganz durch bin ich mit dem Refactoring aber noch nicht. Das Handling der Profile möchte ich noch verbessern. Außerdem lohnt sich bei so umfangreichen Änderungen am Ende sicher noch einmal ein genauer Blick auf die Interresource-Calls.

Ich halte euch auf dem Laufenden....

Jirka

Na los, dann hier die Begriffsdefinitionen:

Subbanding

Hat nichts mit Funk zu tun. 😉

Beim Rendern eines Glyphen wird das Zeichen nicht zwingend komplett auf einmal gerendert, sondern kann in mehrere horizontale Streifen zerlegt werden. Das hilft vor allem bei großen Pointsizes oder knappem Speicher.

Für PC/GEOS ist das wichtig, weil wir im Real Mode nicht beliebig große Renderbuffer anlegen können.

Profile bei TTF

Der TTF-Treiber zerlegt die Outline eines Glyphen zunächst in einfachere Primitive. Die Outline besteht aus Linien sowie quadratischen und kubischen Bezierkurven. Die Bezierkurven werden dabei solange zerschnitten bis nur noch monotone Abschnitte übrig sind. Diese wiederum werden so lange zerschnitten bis sie durch einfache Linien angenähert werden können. Am Ende bleiben nur noch Linien mit ihrer Steigung, die erwähnten Primitive. Zu jedem dieser Primitive kommen noch ein paar wenige administrative Infos und das sind dann die Profile.

Interresource Calls

Das ist GEOS-spezifisch.

Ein Treiber besteht, wie viele andere Geoden auch, aus mehreren Code Ressourcen. Wenn es nun notwendig ist aus einer Code Ressouce eine Funktion aufzurufen ( zu callen) die in einer anderen Code Ressource liegt, dann ist das ein Interressource Call.

Warum ist das für Optimierungen so interessant?

Sämtliche Code Ressourcen des Treibers befinden sich nicht zwangsläufig (das ist eher eine sehr seltene Ausnahme) im Heap. D.h. bevor ein solcher Interresouce Call ausgeführt werden kann muss erst geguckt werden ob das Ziel des Call bereits im Heap liegt. Ist das nicht der Fall muss die Ressource geladen werden. Das bedeuet aber auch dass erst Platz für die Ressource auf dem Heap geschaffen werden muss und das bedeutet oft dass der Memorymanager erst einmal aufräumen muss um ausreichend Platz zu schaffen. Das ganze ist also recht teuer und ein guter Hebel für Optimierungen.

Hallo Wilfried,

nein, tan brauche ich dafür nicht.

Mit Steigung ist hier kein Winkel gemeint, sondern nur das Verhältnis der Koordinatendifferenzen einer Linie. Der Rasterizer muss vor allem wissen, wie sich die x-Position einer Kante beim zeilenweisen Durchlaufen des Glyphen verändert.

Das lässt sich inkrementell mit Integer- bzw. Fixed-Point-Arithmetik berechnen. Trigonometrische Funktionen wären dafür weder nötig noch sinnvoll — und vermutlich auch viel zu teuer.

Gruß
Jirka

Der PR ist nun angelegt. Für die Interessierten hier im Forum noch die erreichten Messwerte:

Nimbus Sans hat überproportional profitiert da eine Optimierung nur für Fonts mit Kerningpaaren wirkt. Von den drei gemessenen Fonts ist Sans der einzige der Kerningpaare enthält. Es gab auch weitere Optimierungen, da GEOS aber nur in Ticks (das sind ca 16ms) messen kann, spiegeln dieses sich nicht in den Messergebnissen wieder.

Dennoch bin ich mit den Ergebnissen sehr zufrieden.