RedeemerSVG.TSVGImage - Kleine SVG-Unit für Delphi mit GDI

[Redeemer]

Da ich für ein eigenes Projekt SVG-Unterstützung (für Tiny 2.0, statisch) brauchte, aber mit den bestehenden Lösungen nicht zufrieden war (viel zu viele benötigte fremde Pakete), habe ich mir kurzerhand selbst eine geschrieben, die nur mit den Delphi-Canvas-Funktionen und GDI (nicht GDI+) arbeitet. Der Quelltext ist relativ klein. Es werden mein eigener XML-Reader (wegen der vielen nicht zwingend zu schließenden Tags) und diverse Parser, z.B. für Style-Angaben, verwendet. Die eigentliche SVG-Klasse ist etwa 1000 Zeilen lang. Der mit Abstand größte Teil des Projekts, das mit Vanilla-Delphi ab 2009 (wegen Generics) kompiliert, ist die Tabelle mit den XML-Entities (was nicht mal Inkscape unterstützt)... Alles in allem kompiliert derzeit zu gerade mal 150 KiB und LZMA-gepackt irgendwo bei unter 30 KiB plus PNG-Image wenn ihr das nicht schon nutzt.

Funktionsweise:

• Es werden zwei TPNGImages (ich arbeite gerne damit, später eventuell Umstellung auf TBitmap) erstellt, eine in RGB für Farbe und eine in Graustufen für Deckkraft. Diese sind derzeit 3× breiter und höher als das Zielbild. Außerdem wird ein SVG-Kontext erstellt. Dieser enthält alle Style-Informationen und wird weitergereicht.
• Anschließend werden die SVG-Elemente verarbeitet:
  • Der Stil wird aus den Attributen und dem style-Attribut geladen. style überschreibt andere Attribute. SVGTiny kann standardgemäß keine richtigen Stylesheets lesen, nur style-Attribute.
  • Zunächst einmal wird ohne Transformationen, aber mit einer erhöhten Genauigkeit (32× breiter und höher, um auszugleichen, dass GDI nur Ganzzahlen kann) mit den GDI-Pfadfunktionen auf eins der PNG-Bilder gezeichnet (bzw. so getan, als ob).
  • Der SVG-Kontext wird in den Brush, Pen, Font und weitere Optionen (Umgang mit Überlappungen, später Gehrung) der beiden PNG-Canvases geschrieben. Wannimmer Farben gesetzt werden, wird beim DeckkraftPNG stattdessen clWhite geschrieben. (Es gibt zwar genau für das Zeichen immer in Weiß eine Funktion beim einfachen Pen (den auch TPen kapsel), aber nicht beim erweiterten ExtCreatePen-Pen.)
  • Der Pfad wird mit GetPath in ein tagPOINT-Array geladen und anschließend aus dem PNG gelöscht. Auch Formen und die für Text verwendete ExtTextOut-Funktion ergeben einen solchen Pfad.
  • Die Punkte des Pfades werden mit allen weiteren Transformationen (affine Abbildungen) versehen und anschließend auf beide PNGs wieder gezeichnet (PolyDraw ist die Umkehrfunktion von GetPath). Die Transformationen finden mit Extended-Gleitkommazahlen statt und haben wie erwähnt eine 32-fache Grund-Genauigkeit. Erst direkt vorm finalen Zeichnen wird gerundet, sodass eine sehr hohe Qualität entsteht, obwohl GDI nur mit Ganzzahlen arbeitet. PS: Der Name dieser Funktion und ihrer Unit stehen nicht zur Diskussion.
• Die Scanline des Deckkraft-PNG wird in die AlphaScanline des Farb-PNGs geschrieben.
• Das sich ergebende PNG wird mittels meines ungewichteten Downscale-Algorithmus um den Faktor 3 je Achse verkleinert, um ein Antialias zu erzeugen. Das Ergebnis ist ein PNG-Bild mit ausreichend hübschem Antialias (TSVGImage leitet sich derzeit von TPNGImage ab, irgendwann könnte man das vielleicht zu TBitmap ändern).

Nennenswerte Einschränkungen:

• Keine Halbtransparenz (Transparenz gibt es aber), da GDI keine Halbtransparenz zeichnen kann. Ich hatte überlegt, eine 10-stufige Halbtransparenz mittels 3×3-Muster (hierbei wird völlige Transparenz unterstützt) zu implementieren, das sähe allerdings an Kanten etwas ungleichmäßig aus und das Überlagern mehrerer solcher Objekte ergäbe kein sinnvolles Ergebnis. Prinzipiell könnte man ein drittes PNG nehmen, darauf zeichnen und anschließend an den bemalten Stellen die Berechnungen mit der Scanline durchführen. Aber will man das? (Bevor jemand fragt: Der TPenMode pmMerge sorgt dafür, dass bei jedem RGB-Kanal der jeweils hellere Wert genommen wird.)
• Keine Farbverläufe und Filter.
• Diverse exotische Attribute und Eigenschaften, jeweils fast ausschließlich beim text-Element, werden nicht unterstützt.
• Die path-Befehle Catmull-Rom (wird als Gerade dargestellt) und Bearing (wird ignoriert) aus SVG2 werden nicht unterstützt.
• Das image-Element.
• Metrische Einheiten.

Details siehe die beiliegende Excel-Tabelle.

Tipps:

• Nach Lesen aller nötigen Informationen des Wurzel-svg-Elements kann die Ausgabegröße mittels Event beeinflusst werden, das SizeCallback heißt und global auf ein folgendes Event gesetzt wird:
  Code:

  type TSizeCallbackEvent = procedure (const Viewport: TRealRect; var Dimensions: TRealPoint) of object;

  So kann das Bild skaliert werden.
• Die Datei RedeemerHypertextColorsX11.pas wird nicht benötigt. Sie liegt bloß für den Fall bei, falls ihr wie ich RedeemerHypertextColors.HTMLToColor anderswo mit X11-Unterstützung brauchen solltet.
• EXE-Demo liegt bei.

Lizenz:
Die Nutzung ist kostenlos. Wer es in einem eigenen Produkt verwendet, das nicht für den Eigenbedarf ist, muss mir eine Nachricht schreiben. Weiterentwicklungen und Ableitungen der Klasse TSVGImage müssen mir auf Wunsch zur Verfügung gestellt werden.

Feedback ist gerne gesehen!

Download (ca. 300 KiB)

Beispielbild der Karte von Niedersachsen von TUBS (Wikipedia). Das Forum kann es leider nicht in der Originalgröße, ich habe es zugeschnitten.
Beispielbild der Flugzeugentführung der Landshut von Devilm25 (Wikipedia). Sie ist nicht ganz perfekt, man sieht ganz gut, was die Engine kann und was nicht. Ich frage mich gerade, warum zwischen der letzten und der aktuellen Version meiner Unit die Grenze zwischen Eritrea und Äthiopien verschwunden ist (sie fehlt allerdings auch bei anderen SVG-Viewern).

[Redeemer]

inherited CreateBlank ruft Create auf. Wenn ich Create überschreibe, gibt's also 'ne endlose Rekursion und damit einen Stack Overflow.

[TiGü]

Zitat von Redeemer:

inherited CreateBlank ruft Create auf. Wenn ich Create überschreibe, gibt's also 'ne endlose Rekursion und damit einen Stack Overflow.

Ja richtig, da habe ich nicht mitgedacht bzw. nicht ausprobiert.

Du musst letztendlich gar nichts hinschreiben und es sollte dann so gehen wie gewünscht:

Delphi-Quellcode:

type
  TMyPngImage = class(TPngImage)
  public
    constructor Create;
  end;

...

{ TMyPngImage }

constructor TMyPngImage.Create;
begin
  inherited CreateBlank(COLOR_RGBALPHA, 8, 1, 1);
end;

[jaenicke]

Das ist einer der Gründe weshalb Konstruktoren möglichst schlank sein sollten. In diesem Fall reicht es doch CreateBlank nicht als Konstruktor zu implementieren (was ohnehin nicht schön ist), sondern als simple Methode. Der überschriebene Konstruktor ruft dann CreateBlank und nur inherited auf, das war es.

[Redeemer]

0.3-alpha ist draußen. Noch ein bisschen schneller (aber unter 10% Gewinn). Link bleibt gleich.
Habe das Create-Problem gelöst, indem ich den benötigten Teil der CreateBlank-Methode kopiert habe.

@TiGü: Nichts hinschreiben und reintroduce sind dasselbe, nur bei ersterem meckert der Compiler.
@jaenicke: Leider ist das im TPNGImage deklariert.

[Redeemer]

So, hier mal ein kleines Update. Oder großes. 0.4-alpha wäre draußen. Kompatibilität hat wieder einen großen Sprung gemacht. Genaues Changelog liegt bei. Link wie zuvor im Anfangspost.

Kleine Info: Das Ding kompiliert wie erwartet ohne Änderungen auch in Vanilla-XE2 und läuft dort etwas schneller (Win32) bzw. merklich langsamer (Win64) als bei 2009. Allerdings ist bereits die Win32-Version des Demo-Programms mehr als doppelt und die Win64-Version mehr als dreimal so groß.

Nächster Schritt wäre, erneut ArcTo zu versuchen und das dann selbst zu berechnen. Vermutlich in 1°-Schritten oder so, da ich nicht weiß, wie man einen Kreisausschnitt in Bézier-Kurven darstellen kann. Falls das jemand weiß, gerne her damit. In GDI gibt es eine Funktion dafür (heißt ebenfalls ArcTo), aber der fehlt leider die Möglichkeit, die x-Achse der Ellipse zu kippen, was SVG kann. Vielleicht spiele ich nachher mal mit Geogebra herum.

Ein weiteres Feature für die nächste Version sind Rasterbilder. Spaß machen hier zwei Dinge: Alphakanal (da dann doch mal) und Transformationen. Vermutlich werde ich ein Rechteck von der Größe des Bildes erstellen und darauf die Transformationen anwenden. Ich bilde dann jeweils die Minima und die Maxima der transformierten Eckkoordinaten. Dann iteriere ich vom Minimum zum Maximum und nutze eine Umkehrfunktion. Wenn ich das richtig sehe, ist eine affine Abbildung, deren Bildraum weder eine Gerade noch ein Punkt ist (in diesen Fällen bräuchte ich das Bild nicht zeichnen), eine bijektive Abbildung, also kann ich die Umkehrfunktion bilden. Bildet die Umkehrfunktion die derzeit iterierte Koordinate auf das Bild ab, kopiere ich den Pixel vom Punkt im Bild. Müsste so klappen.

Langsam merke ich, dass so'n Mathe-Studium doch was bringt.

(Zum angehängten Vergleich: Der Unterschied zwischen 0.2 und 0.3 ist im Innenwinkel des V zu finden. Ich weiß spontan nicht, warum.)

[Redeemer]

Habe Sonntag und Montag den path-Befehl ArcTo implementiert und ein paar Fehler behoben. Ich möchte bis auf weiteres auf image verzichten. Damit ist v0.5-beta die (vorerst) finale Version.
Ich möchte wissen, wer die Klasse in Produkten verwendet, die nicht für den Eigenbedarf sind, daher bleibt eine Nachricht an mich Lizenzbedingung. Die Nutzung ist aber kostenlos.

Zitat von Bernhard Geyer:

Du kannst dir mal anschauen was SVG so bedeutet? Da wird schon einige Mannjahre Entwicklung nötig sein.

[mensch72]

wenn ich deinen Source "real" verwende, bekommst du ne Message


(aktuell ist deine GDI only Stategie für mich ne coole simple Basis, um weitere "XY portatble" Sachen daraus abzuleiten und zu testen)

[Redeemer]

Zitat von mensch72:

(aktuell ist deine GDI only Stategie für mich ne coole simple Basis, um weitere "XY portatble" Sachen daraus abzuleiten und zu testen)

Was meinst du mit XY Portable?

[mensch72]

Da es für EmbeddedSysteme(also XY Hardware mit XY Microcontroler mit RealTimeOS oder Hardcore ganz ohne OS) keine aus meiner Sicht portablen(im Sinn von WinGDI kompatibel) und bezahlbaren GrafikLibs gab, hatte ich mir auf Basis der Analyse von Sourcen alter SoftwareOnly WIN-VGA-Treiber und FullSoftware RDP-Sourcen etwas eigenes "80..90% GDI kompatibles" geschrieben, was letztendlich direkt PixelByPixel im QuadBufferd/Switched-HW-Bildschirmspeicher(den es also 4x gibt) arbeitet.

Zu gut deutsch, ich kann in Grenzen den Visualisierungsteil unter Windows auf GDI-Basis entwickeln und nutze dann den "GrafikSourcecode" in meinen EmbeddedSystemen. Vor vielen Jahren war das mit eigener Hardware durchaus noch sinvoll, dann RaspberryPI, nun innendrin billigster AndroidMassenSchrott der ein integriertes Display hat...

Je besser die HW-Basis und das (OS)API(z.B. auch FMX), um so leichter ist der GDI-API-Adapter "rückwärts" jeweils zu realisieren... zum Schluss ist für mich das funktional/logisch dann alles gleich, weil ich überall (m)einen GDI kompatiblen Grafikcode zur Visualisierung einsetzen kann... und da wird es durchaus cool, statt PixelPildern über die meist weiter sehr langsamen Embedded Kommunikationswege dann lieber SVGs zu übertragen, um daraus dann doch "wieder schöne Darstellungen" live zu erzeugen... mir geht es da also hauptsächlich um die Cachespeicher- & Bandbreitenoptimierung, mit Delphi hat das garnix mehr zu tun

(aktuell verfolgen die Leute von "FMXlinux" bei ihrem "CrossVCL" Projekt den exakt gleichen Grundgedanken, nur gehen die mit GDI+ und OpenGL noch viel weiter... die entwickeln ja auch sagen wir für eine Hardwarebasis mit "DesktopCPU&RAM-Power" )

[TiGü]

Zitat:

Ich frage mich gerade, warum zwischen der letzten und der aktuellen Version meiner Unit die Grenze zwischen Eritrea und Äthiopien verschwunden ist (sie fehlt allerdings auch bei anderen SVG-Viewern).

War Eritrea im Jahre 1977 nicht ein Teil von Äthiopien?