Posts by Jirka Kunze

    Im letzten CI-Build hat sich folgendes am TTF-Treiber getan:

    • Der Render Pool war bisher ein fixer Speicherblock von 4kb Größe. Da fixe Blöcke unter GEOS suboptimal sind ist dieser Block nun zu einem dynamischen Block geworden (kann verschoben oder ausgelagert werden).
    • Die notwendige Größe des Render Pools wird jetzt vor der Benutzung geschätzt. So dass nur soviel Speicher allociert wird wie notwendig ist. Bei typischen Pointsizes (zweistellig) ist das auch deutlich weniger als die 4kb.
    • Bevor ein Zeichen gerendert wird, wird dessen Outline in kleine Einheiten, sogenannte Profile, zerschnitten. Das Handling dieser Profile wurde ein wenig optimiert.
    • Im Rasterizer gab es kleine Umbauarbeiten um das nächste Refactoring vorzubereiten.
    • Mit dem ersten Punkt wurde auch gleich ein Issue gefixt.

    Und zum Schluss fällt mir ein dass dieser Text eigentlich in einen anderen Thread gehört....

    Jirka

    Hallo in die Runde,

    ich habe mich etwas mit der Problematik Gonzo und TTF-Treiber beschäftigt. Die bisherigen Analyseergebnisse deuten darauf hin dass die Ursache in der (noch) zu großen Resource die der Bytecodeinterpreter belegt zu suchen ist. Diesbezüglich benötige ich von euch Testunterstützung.

    Bitte geht mit der aktuellen GEOS-Distribution folgende Punkte durch:

    1) Timeout für den Bildschirmschoner anpassen (ab besten auf 2 Minuten)

    2) Falls Gonzo noch nicht installiert ist, bitte installieren und die Dialoge bis zu Registrierung der Dateiformate durch klicken. Im Dialog für die Dateiformate ok klicken, das sorgt für einen Neustart.

    3) Gonzo starten. Funktioniert dann noch alles?

    4) Warten bis der Bildschirmschoner aktiv wird. Funktioniert das?

    5) GEOS wieder aufwecken. Funktioniert dann Gonzo noch?

    Ich vermute dass es bei 3) bei vielen zum einfrieren/Programmabbrüchen in GEOS kommt. Dann in der Geos.ini folgende Zeilen einfügen:

    [ttfDriver]

    bytecodeInterpreterActive=false


    Danach Punkt 3) bis 5) wiederholen. Funktioniert das?


    Achtung die o.g. Zeilen in der Geos.ini funktionieren nur in der Geos-Distribution ab dem 18.11.2024.


    Danke fürs testen.

    Jirka

    Hallo,

    das Problem scheint einer der berühmten Heisenbugs zu sein(wenn man ihn untersuchen will tritt er nicht auf).

    Nach bisherigen Forschungsergebnissen sind die von Nico erwähnte Stelle im Code aber nur das Symptom und nicht die Ursache....

    Jirka

    Hallo,

    bei der Darstellungsqualität muss man zwischen Treiber und Font unterscheiden. Der Treiber hat seit einigen Wochen alle technischen Features um eine gute Qualität beim Rendern der Zeichen eines Fonts abzuliefern. Die Fonts in der Distribution sind nur noch nicht auf GEOS abgestimmt.

    Die Lösung in der Verbesserung der Qualität heißt Hinting und ist eine Technologie die genau für dieses Problem geschaffen wurde. Momentan sind die Fonts in der Distribution noch via Autohintig gehinted. Nico hat da viel Zeit investiert und mit vielen Parametern experimentiert und ein gutes Ergebnis auf dem Bildschirm zu erreichen. Nun ist es aber so dass das Autohinting Grenzen hat an diese wir offensichtlich nun gestoßen sind.

    Was sind diese Grenzen?

    Da gibt es gleich mehrere. Ein Punkt ist, dass das Grafiksystem von GEOS auf eine Auflösung von 74dpi getrimmt ist. Andere User Interfaces setzen hier auf 96dpi oder mehr. Das bedeutet das für die Darstellung eines Zeichens auf anderen Systemen 33% mehr (also in Höhe und Breite) Pixel zur Verfügung stehen. Ein weiterer Punkt ist sind Techniken wie Subpixel und grayscale Rendering die wir unter GEOS nicht nutzen können da das Fontsystem nur monochrome Zeichen zulässt.

    Warum funktioniert das trotz dieser Grenzen mit den Nimbus Q Fonts so gut?

    Diese Fonts enthalten für kleine Punktgrößen (9, 10, 12, 14 pt) handoptimierte Bitmaps der einzelnen Zeichen. Das bedeutet das bei diesen Punktgrößen garnicht gerendert wird sondern nur die Bitmap kopiert werden muss. Dieser Weg steht uns für die TrueType Fonts auch offen, dazu müsste der Treiber aber erweitert werden und die Fonts müssten um Bitmaps der Zeichen in den besagten Punktgrößen erweitert werden, denn die Fonts die an verschiedenen Stellen im Web herumliegen enthalten alle (zumindest habe ich keine in die Finger bekommen) keine Bitmaps. Das wären dann, bei angenommenen 7 Font in der Distribution, bereits über 25.000 zu zeichnende Bitmaps. Eine Mamutaufgabe....

    Welche Darstellungsqualität ist denn für uns erreichbar?

    Das untere Bild zeigt einen Bildschirmabzug mit einem für monochromes Rendering optimierten Font. Selbst bei einer Punktgröße von 9 ist der Text gut lesbar.

    Es ist das Ziel für die Fonts die letztendlich in der Distribution enthalten sind auf eine solche Qualität zu trimmen. Das wird allerdings nicht ganz einfach. Wie oben beschrieben, werden wir das mit Techniken wie Autohinting leider nicht erreichen. Wie wir das mit dem Hinten der Fonts hinbekommen ist mir bis ins Detail noch nicht klar und Ahnung vom Hinten habe ich keine (das habe ich aber von TTF Fonts vor einiger Zeit auch mal behauptet ). Falls aus der Community sich jemand damit beschäftigen möchte, nur zu, Unterstützung ist gewünscht und jederzeit willkommen.

    Der gezeigt Font ist übrigens einer der mit Windows 3.1 ausgeliefert wurde.


    So, jetzt habe ich wieder sehr weit ausgeholt....


    Jirka

    Noch eine Idee zu den Unterstrichen:

    Es könnte sein dass die Berechnung der Höhe der Bitmap fehlerhaft ist. Diese wird auf Basis der Glyphbox (ein virtuelles Rechteck welches um die Zeichen gezogen wird) berechnet, und da beim Unterstrich sowohl die obere als auch die untere Kante im negativen Bereicht liegt könnte das das Problem sein. Dann würde unter dem Unterschrich das nächste Zeichen im Fontblock gezeichnet werden (das passt zum Bild) und die sekrechten Linien sind die Bytes in Fontblock die noch nicht genutzt werden, denn die sind dann alle mit 0xcc gefüllt.

    Rätselhaft ist nur warum ich das nicht in Writer oder Draw sehe.

    Jirka

    Hallo Rainer,

    das war hilfreich. Ich kann das Problem auch in GeoDraw mit rotiertem Text nachstellen.

    Es deutet einiges auf eine fehlerhaft berechntet Transformationsmatrix hin. Kurios ist das andere Transformationen die in die Transformationsmatrize eingreifen (zB. skew) gut funktionieren.

    Ich denke das ist ein lösbares Problem (und hat auch schon mal funktioniert).


    Was ich nicht in GeoDraw nachstellen konnte sind die Unterstriche die 'Schlieren' nach unten ziehen.

    Jirka

    Hallo Rainer,

    um das Problem einzugrenzen erzähl uns bitte etwas über die verwendeten Fonts.

    Von der Bezeichnung her würde ich sagen das es Nimbus Q Fonts sind. Allerdings heist der Mono Font dann eigentlich URW Mono (also ohne Bindestrich) und der Sans Font URW Sans (also ohne das (Mono) Anhängsel).

    Oder sind das TTF Fonts und du hat den Fontnamen geändert? Wenn ja, kann man das Problem auch in Writer nachstellen?


    Jirka

    Hallo Nico,

    die Fonts sind nur ein Teil des Problems und Fontsquirrel optimiert keine Fonts, sie werden nur anders gehinted. Geos war schon immer ein System das mit bescheidenen Resourcen auskam und aus meiner Sicht sollte das auch so bleiben.

    Für die die es interessiert:

    Ich habe mal die Laufzeiten beim Aufbau der gesamten HIlfeseite (also inkl. Inhalt) ausgeben lassen. Lt. swat hat alles 21,1sek gedauert. Fast 20% davon sind für das Mapping der Geos-Zeichen auf die TrueType IDs benötigt worden. Der zweite große Brocken (ca. 16%) ist das Aufbauen der Chartable Entries im FontBuf. Die beiden Kandidaten werde ich mir als nächsten bei der Optimierung vornehmen. Mal gucken was sich da machen lässt.

    Jirka

    Mist da habe ich beim aufbauen des Systems nicht aufgepasst...

    Hier die korrigierten Werte:

    - DOSBox Staging v0.76.0-1 ubuntu20.04 mit 10000 Zyklen

    - bis der erste Buchstabe gerendert wird braucht es 14sek. bis die gesamte Hilfeseite gerendert ist sind es ca. 24 sek.

    - wie oben beschreiben ist es ein EC Geos mit swat und Kernel mit timer-profile

    Hallo,

    ich habe mal mein System auf den aktuellen master Stand gebracht und versucht das Problem nachzustellen.

    Bei mir sind es etwa 3-4 Sekunden vom Klick auf das '?' in GeoWrite bis zum Zeitpunkt bis die Hilfeseite inkl. Inhalt komplett dargestellt wird. Ich habe meine Dosbox extra auf 5000Zyklen runtergestellt um möglichst lange Ladezeiten zu provozieren. Allerdings teste ich mit einem EC-Geos (das sollte eigentlich deutlich langsamer als die NC Version sein) und einem Geos-Kernel mit aktivem timer-profile und dranhängendem swat.

    Welche Konfiguration habe ich genutzt?

    - DOSBox Staging v0.76.0-1 ubuntu20.04

    - alles läuft unter Ubuntu 22.04.4 LTS

    - ich habe mit den Fonts getestet die seit gestern im master liegen


    Jirka

    Hallo Rainer,

    so ein Zufall dass ich gerade damit arbeite.

    Ich habe zwei Wege probiert:

    1) C-Funktionsrumpf und in der Funktion Inline Assembler. Der Vorteil ist dass alles in einer Source Datei liegt und so der Überblick einfacher ist.

    2) Eine separate Implementierung in reinem Assembler. Damit dennoch alles in einer Ressource liegt wird im asm File der Linker angewiesen den assemblierten Code in das gleiche Segment zu stellen (siehe https://github.com/jirkakunze/pcg…526d23c57e0ec1c)

    Jirka

    Hallo Achim,

    ich würde das Problem gerne genauer untersuchen. Kann das auch in einem GeoWrite Dokument nachvollzogen werden? Wenn ja, welche Pointsize, bei welchen Fonts und Styles und bei welchem Dokumentzoom?

    Jirka

    Hallo Achim,

    schön dass du die CI-Builds testest.

    Ohne genaue Informationen unter welchen Umständen das Erscheinungsbild, das der TTF-Treiber produziert, schlechter als eine vorherige Version ist kann ich keine belastbare Aussage machen woran das liegen könnte. Definitiv kann ich aber sagen dass es nicht an deiner Hardware liegen wird.

    Ab besten du zeigst uns das Problem (Screenshot) am Beispiel einiger Zeichen bei denen die Verschlechterung besonders auffallend ist und nennst und die Konstellation in denen das Bild entstanden ist. Ich denke es gibt eine plausible Erklärung (und Lösung) für das Problem.

    Aktuell sieht es danach aus dass wir unsere Fonts noch deutlich optimieren müssen um eine gute Darstellung auf dem Bildschirm zu erreichen. Das automatische Hinten (so nennt sich der Prozess mit welchem die Darstellung einzelner Zeichen mit etwas Programmcode das im Font steckt verbessert werden soll) hat zwar das Problem gelindert, aber diese Verbesserung wird mit einer deutlich längeren Renderzeit erkauft.

    Jirka

    Über die Bitmapfonts kann ich nicht viel sagen. Die Bitmapfonts werden in den Tiefen des Kernels gelesen und gerendert. Auch der Nimbus-Treiber greift dort nicht ein. Ich vermute es gibt keine Dokumentation die die Struktur der Geos-Bitmapfonts beschreibt. Da bleibt dann nur Reverse Engineering...