Hallo,
auch ich bin in diesem Jahr wieder dabei. Ich werde am Freitag Nachmittag eintreffe und am Sonntag kurz vor Mittag wieder abreisen. Ich werde wieder im Kohrener-Land übernachten.
Was gibt es von mir zu hören und zu sehen:
- Arbeiten am TTF-Treiber der letzen 12 Monate
- Optimierung der TTF-Fonts
- Arbeiten am GEOS PDF-Viewer
- ein VS Code Plugin für GEOS-Entwickler
- eine Überraschung
Jirka
Anbei mal wieder ein kleines Statusupdate zum TTF-Treiber.
Eigentlich wollte ich nur das Stream API des Treibers etwas aufräumen. Wie so oft sind dabei aber noch ein paar weitere Baustellen aufgefallen. 😉
Inzwischen habe ich den Treiber noch einmal auf die für PC/GEOS relevanten Punkte abgeklopft und optimiert: Heap- und Stackbedarf, Binary- und Fixed-Size sowie natürlich die Performance.
Neben dem Stream API sind dabei auch noch einige Optimierungen im Glyph Loader, Rasterizer und Interpreter dazugekommen.
Ein paar Messwerte auf meinem üblichen Testsetup:
| Font | akutelle Alpha Version | Stand im branch |
|---|---|---|
| Nimbus Mono | 183 ms | 150 ms |
| Nimbus Roman | 200 ms | 166 ms |
| Nimbus Sans | 166 ms | 150 ms |
Damit dürfte das größere Optimierungspaket am TTF-Treiber erst einmal abgeschlossen sein. Irgendwann muss man schließlich auch mal aufhören nach dem nächsten Byte oder Taktzyklus zu suchen und sich dem nächsten Dingen widmen. 😉
Hallo Nico,
ich denke das Projekt ist nicht zu retten. Ich habe den Code nur überflogen und sehe nur Probleme:
Ich vermute du hast beim übersetzen jede Menge Warnungen bekommen. Warnungen sollte man sich zumindest man ansehen, denn oft deuten dieses auf echte Probleme hin.
Ich nutze mittlerweile eine KI als Unterstützung. Primär in der Analyse- und Planungsphase und zum Abschluss bei Codereview. Bei letzterem habe ich aber auch schon einige sehr seltsame Anmerkungen bekommen...
Fazit: KI ist eine sehr schöne Unterstützung aber eben kein echter Entwickler.
Jirka
-
Hallo Nico,
ohne den C-Quelltext kann man leider nicht sehen, wo das Programm hängenbleibt.Lade den Quellcode vollständig am besten in ein GitHub-Repository hoch und poste den Link hier. Dann kann sich jeder den Code direkt ansehen.
Wichtiger Hinweis zu ChatGPT: KI-Programme liefern Code in sehr unterschiedlicher Qualität. Daher muss KI-Code immer genau geprüft und getestet werden — einfach kopieren funktioniert leider fast nie und schon gar nicht bei System wie PC/GEOS wo es nicht so viel Code gibt aus der die KI lernen kann.
Hast du dir den generierten Code denn angesehen und verstanden was dort wie gemacht wird? Hast du schon eine Idee was da schief sein könnte?
Wie du hier sicher herausliest: Ich bin kein großer Fan von kompletten Anwendungen/Treibern/Libraries die durch eine KI generiert werden.
Jirka
Nein leider nicht zu wenig Platz (Pixel).
Nico
Es gibt ein paar Tricks die man anwenden kann um einen Glyphen "fetter" erscheinen zu lassen ohne alle Striche breiter machen zu müssen. Man trickst quasi das Auge aus.
PS: ich habe eine weile gebraucht um herauszufinden was mit "Nein leider nicht zu wenig Platz (Pixel)" gemeint ist...
Der PR ist nun angelegt. Für die Interessierten hier im Forum noch die erreichten Messwerte:
| Font | Treiberversion aus der Alpha vom 15.05.26 | Branchversion vom 15.05.26 | Version aus dem Pullrequest |
| Nimbus Mono | 300 ms | 183 ms | 183 ms |
| Nimbus Roman | 350 ms | 200 ms | 200 ms |
| Nimbus Sans | 316 ms | 200 ms | 166 ms |
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.
Danke Rainer,
ich bin gerade am abschließen der letzten Optimierungsaufgabe für den TTF Treiber. Danach kommt dann das Spiel dran.
Danach kommt dann noch was ganz anderes dran...
Jirka
PS: MSR ist die Mecklenburger Seen Runde, das ist ein Radmarathon durch die Mecklenburger Seenplatte (https://www.mecklenburger-seen-runde.de/de). Kann ich wirklich nur empfehlen. Die Runde geht an über 1000 Seen vorbei und ist auch nur 300km lang.
Hi Rainer,
sorry, hier überschlagen sich gerade die Ereignisse und ich habe den Thread aus den Augen verloren...
Das sieht schon richtig gut aus. Darf ich noch um eine kleine Optimierung bitten? Lässt sich die Höhe des grünen Bereichs unterhalb der Spielsteine etwas verkleinern, so dass diese der Höhe des grünen Bereichs oberhalb der Spielsteine entspricht? Das sieht symmetrischer aus.
Ich vermute die Bilder sind mit dem neuen Icon Eddy entstanden?
Jirka
PS: dieses Wochenende findet die MSR statt. Danach habe ich wieder etwas mehr Zeit für die GEOS Entwicklung.
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
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.
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:
Treiber aus dem Branch ttf-driver-remove-ttcache:
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
Es ist beeindruckend zu sehen, was passiert, wenn verschiedene Talente an einem Strang ziehen. Dass wir heute über Dinge diskutieren, die vor Jahren noch undenkbar schienen, liegt an diesem besonderen GEOS Spirit auch hier im Forum. Ich freue mich darauf, gemeinsam mit euch die Grenzen des Systems weiter zu verschieben – lasst uns diesen Schwung beibehalten!
Hm. einen Skalierungsfaktor von 1600% sehe ich kritisch. Bei ausreichend großer Pointsize in GeoDraw und GeoWrite werden gerenderte Glyphen nicht mehr in einen 64kb Block passen. Dieses Problem könnte auch schon bei Faktoren > 400% auftreten.
jk
Schön das meine Bitte doch noch erhört wird.
Hier ein paar Beispielscreenshots:
1) completetely straight unobstructed line:
2) single bend path
3) two turn path:
Wenn du nach
%ROOT_DIR%/Tools/build/product/bbxensem/Scripts
wechselst, funktioniert dann folgender ohne das Kopieren von newgetopt.pl noch?
perl -I. buildbbx.pl
Ursache gefunden und beseitigt. Im aktuellen Release ist dann wieder alles i.o.
Die Problemursache war schlicht und einfach dass ich das TTF-Cache File im PR an die falsche Stelle geschoben habe. Kann ja mal passieren...
Ja, so ist es unter G6. Dokumente und Programme die bspw. URW Sans nutzen, verwenden unter G6 dann Nimbus Sans. Das funtktioniert für alle Nimbus Q Fonts für die in der geos.ini ein Mapping auf TTF Fonts definiert wurde.
Seit gestern gibt es ein neues PC/GEOS 6 Release. Darin ist neben einer neuen (korrigierten und minimal optimierten) Version des TTF-Treibers auch ein neues TTF-Cachefile enthalten.
In dieser Version sollte das geschilderte Problem nicht mehr auftreten. Wer mehr darüber lesen möchte: https://github.com/bluewaysw/pcgeos/issues/1008
Mütze : Es ist tatsächlich auch bei mir so, das mit PC/GEOS 6 erstellte Dokumente z. Z. nicht mit BBE kompatibel sind. Ich weiß auch nicht, ob das jemals so sein wird, denn BBE verwendet Nimbus-Fonts und PC/GEOS 6 TTF-Fonts. Vielleicht kann Jirka etwas dazu sagen.
Mit sind die betroffenen Dokumente zwar nicht bekannt, aber wenn diese TTF-Fonts enthalten, dann wird (vermutlich) unter BBX anstelle dieser Fonts der Default-Font greifen. Das bedeutet dass die Dokumente unter BBX anders aussehen werden. Ein Fontmapping von TTF Richtung Nimbus Q ist nicht geplant, da GEOS 6 als Nachfolger von BBX geplant ist. Manchmal ist es auch gut alte Zöpfe abzuschneiden...
Jirka
Ich bin auch für die aufgeräumte Version des Fonts. Mir ist allerdings nicht klar ob ich in diesem Fall mit ja oder nein abstimmen soll 
Jirka
