Infos zum GEOS TTF-Treiber

  • Hallo in die Runde,

    In verschiedenen Threads hier gab es ein paar Fragen zu den TTF-Fonts. Um die anderen Threads nicht zu 'verunreinigen' haben ich hier ein paar Infos zusammengestellt um den interessierten Nutzern einen kurzen Überblick zu geben.

    Wie ist der Stand der Dinge?

    Der TTF-Treiber muss eine definierte Schnittstelle zum Kernel erfüllen. Das tut er aktuell (damit ist der Stand in github gemeint) zu ca. 90%. Für die letzten 10% habe ich eine (noch nicht stabile) Implementierung hier 'rumliegen'. Ein Weg diese zu testen ist gefunden, jetzt muss der Code noch stabilisiert und weiter getestet werden. War das erfolgreich, dann ist die Schnittstelle zu 100% erfüllt.


    Was geht und was geht nicht?

    Im Treiber haben wir mittlerweile eine künstliche Begrenzung der Fonts eingeführt. Aktuell werden nur noch TTF-Fonts mit max. 2000 Zeichen akzeptiert. Warum das? Fonts mit einer sehr großen Anzahl von Zeichen belegen sehr viel Hauptspeicher bereits beim ersten laden. Konkret ist das bei einem GNU Font aufgefallen der ca. 10500 Zeichen enthielt. Das hatte zur Folge das GEOS unbenutzbar wurde. Es gibt aber die Möglichkeit solche großen Fonts zu reduzieren, dann können sie auch unter GEOS genutzt werden. Grundsätzlich ist das Speicherhandling im Treiber noch nicht 'GEOS-freudlich' mehr dazu weiter unten.


    Darstellungsqualität bei kleinen Punktgrößen?

    GEOS rendert Fonts als s/w Bitmaps. Werden Vektorfonts auf kleinere Punktgrößen heruntergerechnet machen sich Rundungen (man kann einen Pixel ja nur setzen oder nicht setzen) besonders stark bemerkbar. Zu sehen ist das an Ausfransungen an den Rändern von Zeichen, Asymetrien oder fehlende Pixel. Eine Technik namens Hintig soll diesen Darstellungsproblemen entgegenwirken. Dieses Hinting ist im TTF-Treiber aber noch deaktiviert da es wieder viel Speicher beansprucht (eigentlich ist es noch komplizierter), denn mit aktiviertem Hintig wird der Treiber sehr instabil. Es ist aber geplant diese Probleme anzugehen und das Hintig zu aktivieren, allerdings muss der Font das Hintig auch unterstützen. Meine Erfahrung sagt das neuere Fonts das nicht immer tun. Auf anderen Systemen ist das auch nicht notwendig da die genannten Darstellungsprobleme mit anderen Techniken vermieden werden (Anti-Aliasing oder Subpixel). Woran kann man erkennen das ein TTF-Font Hinting unterstützt? Da muss in den Font 'hinein' geguckt werden. Enthält der Font Tabellen vom Typ 'prep', 'cvt' und 'fpgm' (und diese sind nicht leer) dann wird das Hintig unterstützt. Es gibt eine Reihe von Tools die die innere Struktur eines Fonts anzeigen können.


    Was sind die nächsten Schritte?

    Zunächst sind die o.g. fehlenden 10% verfollständig und stabilisiert werden. Dann muss das Speicherhandling des Treibers noch überarbeitet werden (aus meiner Sicht die unangenehmste Aufgabe) und das Hinting für GEOS fit gemacht werden.


    Welche Probleme gibt es noch?

    Aktuell gibt es noch drei offene Bugs (in github ist das #272, #273 und #274). Eventuell ist #272 bereits durch Korrekturen am Font-Mapping gefixt. Das wäre noch zu testen. Dann muss die Performance des Treiber noch deutlich verbessert werden. Ein direkter Vergleich der Renderzeiten von Nimbus und TTF-Treiber wäre auch noch interessant um herauszufinden wieviel da noch zu tun ist. Da die Font Funktionen im Kernel quasi für die Struktur der Nimbus-Fonts 'maßgeschneidert' wurden wird der TTF-Teiber die Performance des Nimbus-Treibers nicht erreichen können.
    Das Hauptproblem wird aber die mir zu Verfügung stehende GEOS-Zeit sein. Die ist seit einigen Monaten deutlich gesunken. Ich hoffe ist wird bald wieder besser...

    Ich hoffe ich bin bei meine Ausführungen nicht zu technisch geworden.

    Jirka

    Es ist auch dein FreeGEOS!

  • Danke für das Update, Jirka!

    Um diese Idee hier etwas zu unterstützen...

    Dann muss die Performance des Treiber noch deutlich verbessert werden. Ein direkter Vergleich der Renderzeiten von Nimbus und TTF-Treiber wäre auch noch interessant um herauszufinden wieviel da noch zu tun ist. Da die Font Funktionen im Kernel quasi für die Struktur der Nimbus-Fonts 'maßgeschneidert' wurden wird der TTF-Teiber die Performance des Nimbus-Treibers nicht erreichen können.

    ...habe ich mal eine kleine Ergänzung an meinem Font Lister gemacht, so dass er auch die ungefähre Rendering-Zeit für einen Buchstaben anzeigen kann. Dazu werden die Buchstaben A bis Z nacheinander in 29pt (wofür es hoffentlich fast nirgendwo optimierte Bitmaps gibt) in einen Bitmap-GString gemalt und die Zeit gestoppt. Das geht zwar pro Systemstart nur einmal (danach ist der Font-Cache gefüllt), aber eine Idee gibt es schon mal. Im Moment würde ich grob einen Faktor 10-12 zwischen TTF und Nimbus sehen:

    Den Quellcode gibt es hier: https://github.com/mgroeber9110/freegeos-font-lister

  • Anbei ein kleines Statusupdate.

    Was gibt es Neues?

    Die Implementierung des GEN_IN_REGION Handlers ist erfolgreich abgeschlossen. Das bedeutet die Schnittstelle die der Treiber erfüllen muss ist jetzt zu 100% fertig. Die Änderungen sind bereits in master und im neuesten CI-Build enthalten. Mit der neuen Version des TTF-Treibers funktioniert nun auch Gonzo wieder.

    Was ist noch zu tun?

    Auf der ToDo-LIste stehen noch folgende Aufgaben:

    • Speicherhandling des Treibers an die Bedürfnisse von PC/Geos anpassen
    • Bytecodeinterpreter aktivieren
    • Speicherbedarf, Binarysize und Performance optimieren
    • Offene Bugs (sind aktuell (nur) 2) und alles andere was unterwegs noch so auffällt

    An was wird gerade gearbeitet?

    Ich habe jetzt begonnen mich mit dem Speicherhandling des Treibers zu beschäftigen. Ein erster Block ist bereits von einen fixed Block zu einem movable und swapble Block geworden. Es müssen aber noch ein paar weitere folgen.

    Zusammenfassung und Ausblick

    Vor dem Umbau des Speichermanagement hatte ich schon Angst Respekt. Die ersten Schritte in diese Richtung haben aber gezeigt dass es wohl doch nicht so übel wird wie befürchtet. Es wird allerdings eine Mischlösung werden. D.h. die vielen kleinen Speicherschnipsel (je nach Font sind das eine größere Anzahl von denen jeder einzelne oft nur 16 oder 32 byte groß ist) verbleiben in den fixen Blöcken zu jeweils 1kb. Die großen Brocken werden werden zu movable/swapable Blöcken.

    Das Aktivieren des Bytecodeinterpreters wird sicher auch noch so einige Problem unter Geos machen. Das kommt aber nach dem Refactoring des Speichermanagements.


    Ich hoffe ich habe jetzt nicht zu viel technisches eingestreut....


    Jirka

    Es ist auch dein FreeGEOS!