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

[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?

[TiGü]

So kannst du im LoadFromStream eine handvoll Millisekunden sparen:

Delphi-Quellcode:

  sl: TStringStream;
begin
  sl := TStringStream.Create('', TCustomUTF8Encoding.Create);
  try
    sl.LoadFromStream(Stream);
    XML := TRedeemerXML.Create(sl.DataString);
  finally
    sl.Free;
  end;

[Redeemer]

Kleine Frage mal an die, die die Klasse benutzen: Mit welchen Delphi-Versionen kompiliert die? Müsst ihr was anpassen?

Zitat von 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?

Absolut korrekt, danke. Das erklärt's. Dann hat wohl der Ersteller der Karte die entsprechende Grenze mit irgendwas übergekritzelt, was zu der Zeit, als die Grenze da war, noch nicht unterstützt wurde.

Zitat von TiGü:

So kannst du im LoadFromStream eine handvoll Millisekunden sparen:

Delphi-Quellcode:

  sl: TStringStream;
begin
  sl := TStringStream.Create('', TCustomUTF8Encoding.Create);
  try
    sl.LoadFromStream(Stream);
    XML := TRedeemerXML.Create(sl.DataString);
  finally
    sl.Free;
  end;

Brachte in meinem Test überhaupt selbst mit einer 6 MiB großen SVG-Datei keinen Unterschied, außer dass die EXE 1,5 KiB größer wurde. Gestört hat mich das mit TStringList auch schon. Mich stört auch, dass der String beim Laden aus einem TMemoryStream (was in dem Projekt, wofür ich es benötige, üblich ist) zeitweise dreimal im Speicher ist. TByteStream sah auch Interessant aus, aber ich benutze mit Pos und Copy einige Funktionen, die nur für Strings (genau so) funktionieren.