GDI, GDI+ oder doch Direct2D?

[Jazzman_Marburg]

Hallo Graphik-Experten!
Irgendwie komme ich gedanklich an folgender Frage nicht weiter -- und das große Internet hat mich jetzt mehr verwirrt als das es geholfen hat. Mein Anliegen:
Die Applikation soll

• Grafiken (BMP, JPG oder PNG) laden
• sie anzeigen
• User kann die Farbe der Grafik ändern können
• die Grafik soll im Ursprungstyp (BMP, JPG oder PNG) gespeichert werden.

Jetzt dachte ich, ich erstelle für jeden Grafik-Typ ein entsprechendes Objekt:

• if graphtype = 'PNG' then myGraph := TPngImage.Create;
• if graphtype = 'BMP' then myGraph := TBitmap.Create;
• if graphtype = 'JPG' then myGraph := TJpeg.Create;

Für das Anzeigen der Grafik, dachte ich, muß ich die Grafik einem TImage übergeben:

• bmp := TBitmap.Create;
• bmp.width := myGraph.width;
• bmp.height:= myGraph.height;
• bmp.canvas.draw(myGraph,0,0);

Nach der Änderung durch den User, speicher ich die Grafik wieder im Ursprungs-Typ:

• myGraphOut : TGraphics
• myGraphOut.width := bmp.width;
• myGraphOut.canvas.draw(bmp);
• myGraphOut.savetofile(whatever)

Jetzt kommen wir zum Casus-Knacktus:
Wenn ich doch intern Alles, was da kommt in ein BMP verwandle, dann habe ich doch mindestens das Problem, dass z.B. der Alpha-Channel des PNG futsch ist. Das kann also nicht das gelbe vom Ei sein.
Zugegebenermaßen, habe ich in der EmBa-Newsgroup eine hähnliche Frage gestellt, und dort wurde mir dann GDI+ empfohlen. Ich kenne mich GDI+ nicht aus, aber wieso sollte das die Lösung sein?
Und vor allem: Die Applikation soll nur auf Win7 laufen -- dann könnte ich ja gleich Direct2D nutzen, oder?

Das alles klingt vielleicht komplizierter als es vielleicht wirklich ist (anzeigen, ändern, speichern) -- aber ich bin nun wirklich verwirrt, was ein gangbarer Weg zu dieser kleinen Applikation ist.

Könnt ihr helfen?

Vielen Dank
Jazzman

[xaromz]

Hallo,

kurz vorneweg, ich kenne mich bisher mit Direct2D nicht aus, kann dazu also nichts sagen.
Ich kann Dir aber sagen, dass GDI+ geeignet für Dein Vorhaben ist. Und zwar einfach, weil GDI+ verschiedene Graphikformate unterstützt, unter anderem auch PNG. Das Schöne dabei ist, dass Du immer nur mit einem Objekt "Image" arbeitest, in dem dann die verschiedenen Formate drinstecken. Außerdem hast Du natürlich viel mehr Funktionen (Transparenz, Antialiasing, Pfade...).

Gruß
xaromz

[Jazzman_Marburg]

Dankeschön für die klare Aussage!

Die Hinweise verdichten sich also zu: GDI+ :coder:

Habe damit zwar noch nie etwas gemacht, aber es scheint die richtige Grafik-Umgebung für mein Vorhaben.

Vielen Dank!

Gruß
Jazzman

[turboPASCAL]

Zitat:

Zitat von Jazzman_Marburg (Beitrag 1100394)

Die Hinweise verdichten sich also zu: GDI+

Jupp. ;)

[Memnarch]

Nein, beim laden in die TBitmap geht der alphachannel nicht verloren.

Einfach vorm laden PixelFormat auf pf32Bit stellen.

Es ist halt nur so, dass nicht alle funktionen in delphi den alphachannel berücksichtigen(beim zeichnen).

Wenn du beim zeichnen sicher gehen willst, nimmste einfach AlphaBlend (api funktion).

(damit hab ich schon unter D7 mit 32bit bitmaps alphatransparenz gezeichnet(per pixel).

MFG
Memnarch

[implementation]

OpenGL im 2D-Modus könntest du auch noch benutzen. Da kannst du dann auch noch so schöne Dinge machen wie Skalierung, Verzerrung usw.
Allerdings müsstest du dann für die verschiedenen Formate noch zusätzliche Loader einbinden.

GDI+ kann schon alle (auf Windows gängigen) Formate von Haus aus und kann Skalierung, Verzerrung, Drehung & Co. ebenso gut.
Nachteil an GDI+: Es ist schweinelangsam verglichen mit OpenGL oder Direct2D.

Für deinen Zweck sollte die GDI+ jedoch die beste Wahl.
Du könntest einerseits die Farbe Pixel für Pixel ändern - oder aber eine halbtransparente Schicht drüberlegen - dank ARGB ganz einfach.

[rollstuhlfahrer]

GDI+ kann alles, was GDI auch schon kann und noch ein paar Extras. Außerdem hast du nicht die Probleme mit den Delphi-Typen ala TBitmap, TJPEGImage, TPNGImage, TGifImage, ... (siehe Vorredner). Weiterhin ist es mit GDI+ möglich, alle vorhandenen Operationen auf alle unterstützten Graphiktypen anzuwenden. Die Delphi-Typen werfen in solch einem Fall schon mit Fehlermeldungen um sich, wenn man nicht am TBitmap rumschrauben will.

Das GDI+ langsam sein soll, kann ich jetzt nicht bestätigen, da ich a) nicht weiß, wie schnell OpenGL und Direct3D sind, b) in der VM keine 3D-Graphikunterstützung habe und c) das ganze noch nicht im Batch-Modus ausprobiert habe. Es kommt halt auf das erwartete Tempo an.

Nachteil: Du solltest nicht TImage als visuelle Komponente verwenden, sondern dir einen eigenen Image-Container schreiben, da sonst z.B. der Alpha-Kanal nicht beachtet wird (TImage => Bitmap).

Bernhard

[Memnarch]

@Rollstuhlfaherer: GDI/GDI+ -> CPU
OpenGL/Direct3D -> GPU

Daher auch in erster Linie der geschwindigkeitsunterschied.
Wieweit man GDi/GDI+ optimieren könnte, sei dahin gestellt.


MFG
Memnarch

[rollstuhlfahrer]

Zitat:

Zitat von Memnarch (Beitrag 1100464)

@Rollstuhlfaherer: GDI/GDI+ -> CPU
OpenGL/Direct3D -> GPU

Nun ja, das merkt man wohl auch nur, wenn man Hardwarebeschleunigung aktiv hat, was bei mir definitiv nicht der Fall ist. Bei mir läuft beides auf der CPU.

Grund: Der GraKa-Treiber und mein Ubuntu vertragen sich nicht.

Bernhard

[Thom]

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1100453)

Du solltest nicht TImage als visuelle Komponente verwenden, sondern dir einen eigenen Image-Container schreiben, da sonst z.B. der Alpha-Kanal nicht beachtet wird (TImage => Bitmap).

Wieso denn das? Selbstverständlich kann TImage in Zusammenarbeit mit TPNGImage Transparenz darstellen!

[rollstuhlfahrer]

Gut, dann änder ich mal schnell meine Begründung: TImage ist zwar toll, aber es kann nicht mit GDI+ zusammen arbeiten. Dazu muss man zuerst das Bild in ein Delphi-kompatibles Format bringen und kann es erst dann anzeigen. Da GDI+ selber zeichnen kann, würde ich diese Zeichenroutinen bevorzugen.

Zitat:

Zitat von Thom (Beitrag 1100506)

Selbstverständlich kann TImage in Zusammenarbeit mit TPNGImage Transparenz darstellen!

Ist mir auch wieder eingefallen, dass das mit den PNG-Komponenten geht.

Bernhard

[Thom]

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1100508)

TImage ist zwar toll, aber es kann nicht mit GDI+ zusammen arbeiten.

:gruebel: Tut mir leid, wenn ich wieder herumnörgle - aber das geht sehr wohl (Voraussetzung: Image1 enthält ein PNG-Bild):

Delphi-Quellcode:

uses
  ..., GDIPAPI, GDIPObj, GDIPUTIL;

//...

procedure TForm1.Button1Click(Sender: TObject);
var
  Graphics : TGPGraphics;
  Brush: TGPSolidBrush;
begin
  Graphics:=TGPGraphics.Create(TPNGImage(Image1.Picture.Graphic).Canvas.Handle);
  try
    Brush:=TGPSolidBrush.Create(MakeColor(128,255,0,0)); //Alpha=128 entspricht 50%!!!
    try
      Graphics.FillRectangle(Brush,10,10,20,20);
    finally
      Brush.Free;
    end;
  finally
    Graphics.Free;
  end;
  Image1.Invalidate;
end;

[implementation]

[OT]

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1100467)

Grund: Der GraKa-Treiber und mein Ubuntu vertragen sich nicht.

Oh, was hast'n du für 'ne GraKa? Unter meinem läuft alles wunderbar, auch inner Virtualbox mit Windows drin.
[/OT]

[christian.noeding]

Hallo zusammen,


ich kram diesen Thread aus dem Mai noch einmal hervor, da hier noch Fragen unbeantwortet sind, welche mich aber derzeit ebenfalls beschäftigen und dieser Thread über die Suche einem entgegenspringt :). Die Ursprüngliche Frage war ja: GDI, GDI+ oder Direct2D (per TDirect2DCanvas)?

Die Infos im Netz verwirren hauptsächlich, da jeder eine Meinung hat (schön), die aber meist das Gegenteil der anderen Meinung darstellt (das ist nicht so schön *g*). Nun die Frage: Kann mir jemand eine Aussage geben, welche Zeichen-Methode die optimale Lösung ist, um bei Windows 7 mit Hardwarebeschleunigung eine Oberfläche zu zeichnen? Unter "Oberfläche" verstehe ich:

• PNG-Bilder einfügen (per Maus verschiebbar - ähnlich Windows-Desktop)
• Text zeichnen
• Linien zeichnen und diese möglichst schnell aktualisieren (für Statusanzeigen)

Ein Beispiel meiner aktuellen Implementierung mit GDI (ohne Plus) findet man im Anhang. Es handelt sich um die grafische Darstellung meines Lichtprogramms. Alle Elemente werden live gezeichnet.

• GDI (ohne Plus) wird ja wohl bei Windows 7 nicht mehr per Hardware beschleunigt. Ich hab da aber auch unter XP aufgrund vieler PNG-Bilder meist nur mit 15 FPS gearbeitet, damit die CPU-Auslastung durch das Repainting nicht zu hoch wird (BitBlt).
• GDI+ soll ja unter Windows7 wieder Hardwarebeschleunigt sein. (SynGDIPlus-OpenSource Methode, um TCanvas mit GDI+ zu zeichnen - ist das sinnvoll und performant?)
• Mit TDirect2DCanvas hab ich noch keine Erfahrung.

Hier noch eine Quelle, wo auch (eher ergebnislos) zwischen Direct2DCanvas und GDI+ diskutiert wurde: Chris Bensen Blog: TDirect2DCanvas-Performance

Noch einmal: was wäre die optimale Zeichenmethode, um möglichst schnell mit oben angegebenen Voraussetzungen zu zeichnen?


vielen Dank,
Christian :wink:

[EWeiss]

Was spricht gegen eine kombination von GDI+ und OpenGL ?
Ich mach nichts anderes und läuft hervorragend.
Was die Hardware beschleunigung angeht.. na ja und das andere halt auch.

Transparentes OpenGL Fenster in verbindung mit Blur/Crytal Effekt und aufgesetzen *.PNG's mit GDI+ feine sache
wenn man drauf steht natürlich.


gruss

[franktron]

Warum nicht ganz einfach FMX nutzen wenn man schon XE2 hat, das ist doch OpenGL oder DirectX und schön schnell.

[TiGü]

Zitat:

Zitat von franktron (Beitrag 1174038)

Warum nicht ganz einfach FMX nutzen wenn man schon XE2 hat, das ist doch OpenGL oder DirectX und schön schnell.

Ganz einfach:
Eine VCL-Anwendung komplett auf eine FMX-Anwendung umzugestalten ist aufwendig und die Zeit bezahlt einen keiner.

[christian.noeding]

Hallo,

danke schon einmal für die Antworten. Firemonkey kann ich nicht einsetzen, da das Hauptprogramm ein herkömmliches VCL-Programm ist. Die Anzeige soll als Docking in die Hauptanwendung eingebaut werden. Soweit mir bekannt ist kann ich FMX-Fenster nur per DLL (oder mit sehr teuren Tools) in die VCL-Anwendung integrieren.

@EWeiss: wie sähe die Kombination von GDI+ und OpenGL aus? Google spuckt da zwar viel aus, aber wenn Du nen kleinen Tipp hast wäre das gut.

Kann einer eine Aussage zum Vergleich TDirect2DCanvas <-> GDI(+) machen? Wenn das TDirect2DCanvas flott genug für 25 FPS ist, wäre ich damit ja schon zufrieden :) Ich kanns auch selber ausprobieren, aber wenn da jemand schon Erfahrung hat, brauch ich nicht extra zig Zeilen Code schreiben, um dann festzustellen, dass die Lösung langsamer als die Alte ist.


besten Dank,
Chris

[blackfin]

Zitat:

25 FPS

Wenn du 25fps brauchst, würde ich generell von einer CPU-basierten Lösung wie GDI+ abraten und gleich auf OpenGL /Direct2D gehen.
Vorteil liegt auf der Hand: Volle Leistung der GPU und kein CPU-Krüppelding :-)
Kann zwar gut sein, dass GDI+ in vielen Fällen 25fps schafft, aber der Leistungs-Spielraum nach oben ist bei einer GPU-basierten Lösung um mehrere Faktoren höher.

OpenGL hätte dann sogar den Vorteil, solltest du deine Anwendung irgendwann mal auf mobile Geräte bringen wollen (ist ja zur Zeit nicht so abwegig), kannst du zumindest den OpenGL Code schon teilweise übernehmen, da OpenGL (ES) auf mobilen Geräten der Standard ist.

GDI+ ist etwas, auf das ich bei einer Neuentwicklung nicht mehr setzen wurde.


@EWeiss: wenn du schon OpenGL benutzt, für was brauchst du dann noch GDI+ ? Kann gut sein, dass es in manchen Fällen sinnvoll ist, allerdings fällt mir jetzt spontan nichts ein, worin GDI+ irgend einen Vorteil hätte gegenüber OpenGL, im Gegenteil.
Würd mich deswegen interessieren, warum du die beiden Techniken verbindest und für was?

[Bummi]

@blackfin

bei mir Transparenzen in Komponenten incl. Zoom/Scale/Rotate Antialiasing etc.

[KrasserChecker]

Also ich kann dir da GDI+ sehr ans Herz legen. Habe das in einem meiner letzten Projekte erfolgreichen eingesetzt. Dabei ging es um eine hochperformante 2D-Kartendarstellung mit dyn. Overlays mit bis zu >10.000 Elementen.

Geholfen hat mir dabei diese Bibliothek hier, die den Zugriff auf Gdi+ scehr schön vereinfacht und mit OOP kapselt:
http://www.bilsen.com/gdiplus/index.shtml

[Medium]

Man kann es drehen und wenden wie man will: GDI+ ist praktisch abgekündigt. Natürlich kann man damit noch viele Dinge tun, und es ist in vielen Belangen besser/schöner/schneller als die gute alte GDI, und "legacy" Anwendungen würde ich - sofern bereits auf GDI+ basierend - auch eher zögerlich bis garnicht so massiv umschreiben. Aber es bleibt dennoch abgekündigt, und wird spätestens ab Win8 komplett in Software laufen, und war an und für sich auch vorher schon nie für Programme gedacht, die eine gewisse stabile Framerate einhalten mussten.

Wenn man es "richtig" machen will, und die Geschwindigkeit einfach braucht, und auch im nächsten Windows (oder anderen OS) nicht nackt dasteht, bleibt als größter gemeinsamer Nenner, dessen Standard auch schon seit etlichen Jahren nach unten hin recht beständig und brav behandelt wird - und zwar in Hardware wo möglich - ist OpenGL. Wenn man nach dem besten (Kompromiss aus Geschwindigkeit und Kompatibilität) sucht, ist das eine verdammt gute Antwort.

Natürlich ist der Schwung von GDI zu GDI+ gemütlicher. GDI->OpenGL entspricht einem Rewrite des GUI inkl. einem eigenen VCL-Ersatz, und ggf. auch einem ganzen Haufen Lernaufwand (wir reden über Mannwochen wenn man ganz ohne 3D-API Erfahrung da dran geht und es wirklich verstehen will - sprich von der Pike auf, ohne aufgeblasene und plattformeingrenzende Frameworks). Aber wenn die Frage lautet "was ist das beste?", bleibt OpenGL es eine verdammt gute Antwort, die sowohl einen prima Mittelweg für diverse Anforderungen, als auch auf den meisten Endgeräten eine "nah am möglich machbaren" Performance bietet. End of Story.
Wer möglichst einfach migrieren will, muss anders fragen.

PS: FMX nutzt zwar auch OpenGL, ist aber imho noch viel zu unausgereift und "kantig" (codemäßig) um es in ernsten Projekten einzusetzen. Zudem bringt es, diversen Blogs nach, noch zu viel "bloat" und undurchdachten Code mit sich. Wenn es, jetzt für mich persönlich, um ein kommerzielles Produkt ginge, würde ich einen Teufel tun und auf FMX setzen. Wenn sich alles in XE4 oder so mal langsam gestzt hat, dann guck ich da nochmal drauf.

[blackfin]

Hach, wie ich deine Antworten doch immer so mag *schmunzelt*
Nein, das war keine Ironie!

Meiner Meinung liegt die Hemmschwelle bei OpenGL nur an der extrem steilen Lernkurve...hat man es jedoch mal gerafft (wobei es meiner Meinung nach im Leben nicht möglich ist, allles davon zu raffen), findet man Dinge wie GDI+ eher lächerlich.
Ja, OpenGL wirklich zu verstehen ist schwer, aber wenn sich die Lichter gen Stirn neigen, kann man das CPU-Zeug so gut wie vergessen.
Wo man sich bei GDI+ mit Transparenz oder sonstigen Bild-Manipulationen mit der Performance abkämpft, hat man das Zeug mit Shadern in tausendfacher Performance in OpenGL wesentlich leichter geschrieben.....jedoch, leider nur dann, nachdem man zumindest das Red- und Orange-Book auswendig kennt.

[Namenloser]

Schwer zu verstehen finde ich OpenGL nicht, aber die Verwendung ist mitunter sehr mühsam.

Je nachdem, was man machen will, ist OpenGL mehr oder weniger gut geeignet. Wenn man nur ein einziges Fenster (bzw. Render-Buffer) und eine regelmäßige, statische Renderschleife hat (wie z.B. bei vielen Spielen), ist OpenGL gut geeignet. Wenn man hingegen flexibel Grafiken in verschiedene Buffer rendern will, steigt der Anteil des Boilerplate-Codes enorm an.

Dadurch, dass OpenGL nur einen einzigen, globalen Zustand kennt, muss man nämlich immer daran denken, alle Einstellungen, die man setzt, wieder rückgängig zu machen – und das auch noch möglichst effizient. Wenn man, mal übertrieben gesagt, für jedes Dreieck alle Einstellungen setzt und wieder zurücksetzt, war es das bald mit der überlegenen Performance ;). Die Treiber (zumindest die von NVidia) prüfen leider nicht mal, ob der neu gesetzte Wert sich überhaupt vom alten unterscheidet, sondern führen einfach stumpf die Anweisungen aus. Es liegt also an der Anwendung, den Status zu tracken und redundante Befehle zu vermeiden.

Ein absoluter Performance-Killer ist nach meiner Erfahrung das abwechselnde Rendern in verschiedene Framebuffer-Objects. Leider sind die Treiber nicht intelligent genug, solche Vorgänge ähnlich wie NCQ bei Festplatten zu optimieren, sondern switchen jedes mal hin- und her, was extrem langsam ist. Meine Lösung war am Ende, alle meine Zeichenbefehle zu puffern, indem sie zunächst in einen programminternen Queue geschrieben werden (pro Framebuffer einer), dessen Befehle immer nur in größeren Paketen von z.B. 100 Befehlen tatsächlich ausgeführt werden, um das Context-Switching zu reduzieren. Das führt natürlich selbst wieder zu Overhead, verbesserte die Performance aber buchstäblich um mehrere Größenordnungen.

Generell ist auch ein Problem, dass jeder OpenGL-Treiber sich wieder ein bisschen anders verhält... was bei dem einen Treiber die Performance verbessert, ist bei dem anderen wieder kontraproduktiv usw... da gilt es dann durch viel Experimentieren einen Kompromiss zu finden.

Selbst mit jeder Treiberversion ändert sich das Verhalten wieder. Z.B. gab es von NVidia mal ein paar Treiberversionen, die VSync im OpenGL-Modus über ein Busywait implementiert haben. Ich habe tagelang nach der Ursache gesucht, warum mein Programm auf einmal so eine hohe CPU-Last erzeugt, bis ich gemerkt habe, dass es am Treiber lag...

[christian.noeding]

OK, dann sehe ich für GDI+ und OpenGL schon mal ein paar Pros und Contras. Danke schon einmal für die zahlreichen Infos. Für OpenGL könnte man ja auch unter Umständen Andorra2D verwenden. Man muss das Rad ja nicht komplett neu erfinden. Ich muss aber noch einmal nachhaken: wie sieht es mit TDirect2DCanvas aus, oder ist das noch zu neu, dass es noch keiner verwendet hat? Klingt ja eigentlich laut Beschreibung am vielversprechendsten, da man viele bekannte GDI-Zeichenoperationen weiterverwenden kann.


viele Grüße,
Chris

[Namenloser]

Bei Direct2D sehe ich in erster Linie den Nachteil, dass es erst ab Vista läuft...

[christian.noeding]

Tja,

also zwischen GDI-Canvas mit BitBlt() und Direct2DCanvas kann ich unter Win7 64Bit keinen wirklichen Unterschied feststellen. Wenn ich mit einem Threaded-Timer die Oberfläche bei D2D mit höherer Geschwindigkeit neuzeichne, bleibt zwar die CPU-Belastung nahezu 0% und es wird schnell neugezeichnet, allerdings friert mir das Hauptprogramm ein. Man müsste also die Zeichenroutinen dann in einen Extra-Thread einbauen. Wenn ich einen normalen VCL-Standard-Timer verwende kann ich gar keinen Unterschied zu BitBlt() feststellen.


Im Anhang habe ich ein kleines Demo-Programm, welches beide Varianten verwendet (BitBlt() und D2DCanvas). Ich zähle in der Zeichenroutine einfach eine Word-Variable hoch und skaliere damit mein Rectangle, welches auf der Canvas gezeichnet wird. Bei der GDI-Variante zeichne ich zunächst auf ein TBitmap32 aus der GR32-Sammlung und blitte es dann mit Bitblt auf die Paintbox. Bei der D2DCanvas zeichne ich direkt auf die Canvas. Es ist jetzt wirklich die Frage, ob der Aufwand eines Extra-Zeichen-Threads wert ist, wenn GDI auch unter Win7 noch so gut funktioniert. OpenGL schaue ich mir jetzt als nächstes an.


viele Grüße,
Christian

[Namenloser]

Das so zu messen bringt nichts, weil der Timer selbst der Flaschenhals ist ;)
Wenn dann müsstest du es in einer Schleife testen.

[christian.noeding]

Oh - wie wahr :oops:

Ich erweitere meinen bisherigen Code jetzt erst einmal mit Direct2D-Canvas, da das am wenigsten Aufwand macht (bislang ja GDI). Dann läuft das Programm auch noch unter WinXP, da ich dort dann mit GDI zeichne. Sollte das am Ende immer noch nicht zufriedenstellend schnell laufen, wechsle ich auf Andorra2D.


Vielen Dank an Euch Poster.


Viele Grüße,
Christian

[Namenloser]

Ah, ich wusste nicht, dass TDirect2DCanvas das gleiche Interface wie TCanvas hat (habe ich unter TDE nicht). Ja, in dem Fall würde ich das auch nutzen... mehr Performance wird mit Andorra2D vermutlich auch nicht drin sein.

[christian.noeding]

Ja, Direct2D-Canvas besitzt soweit alle wichtigen Zeichenfunktionen des Standard-Canvas. Von daher braucht man nicht viel ändern. Das habe ich aber auch erst gestern herausgefunden. Hier gibts einige interessante Infos dazu: Using the Direct2D Canvas

beste Grüße!

[Medium]

Ab welchem Delphi gibt es die TDirect2DCanvas Klasse, bzw. alles was da noch bei gehört?

[christian.noeding]

Hi,


scheinbar gibt es das ab Delphi 2010. Hier wird es jedenfalls in der 2010er-Referenz der VCL bereits angezeigt: http://docwiki.embarcadero.com/VCL/2...Direct2DCanvas


ciao

[Medium]

Mist, trotzdem noch zu neu! Danke :)

[Gruber_Hans_12345]

so dann mal diesen extremst alten Thread hochholen, aber der passt halt am besten.

Bin auch gerade am überlegen von GDI auf GDI+, Graphics32 oder doch was anderes umzusteigen.
Ich möchte dabei nicht die ganze GUI umstellen, sondern nur ein Fenster - einen Leitstand.
Da muss ich eben viele Grafiken, transparente PNG, transparente SVG und co zeichnen.
mit GDI ist es halt schon etwas langsam (vorallem wenn ich elemente verschiebe usw. dann muss doch oft gezeichnet werden.)

Was wäre da im Moment das beste dafür?
Müsste es dann noch auf Delphi 2007 bringen, kann aber auch einiges auslagern in eine DLL die mit neuem Delphi gemacht wird, und die dann von der Delphi 2007 App aufrufen.

[TomyN]

Ich denke, mit Graphics32 wärst Du gut bedient.

[mytbo]

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1514348)

Da muss ich eben viele Grafiken, transparente PNG, transparente SVG und co zeichnen.

Bei deinen Anforderungen könnte Image32 einen Blick wert sein. Die Library kann ab Delphi 7 verwendet werden. Die Beispiele benötigen mindestens Delphi 2010.

Bis bald...
Thomas

[Gruber_Hans_12345]

Gibt es wo einen Vergleich zwischen Image32 und Graphics32?

[Jens01]

Zitat:

Gibt es wo einen Vergleich zwischen Image32 und Graphics32?

Image32 ist noch relativ neu. Angus hat aber immer schon an Graphics32 mit rumgewerkelt und versucht sich mit Image32 an ein neues System, was nicht so viele Abhängigkeiten wie Graphics32 hat. Ich vermute, Du kommst mit Image32 schneller an eine Lösung. Graphics32 ist manchmal etwas unübersichtlich, dafür aber mächtiger.

Du kommst ohnehin nicht darum herum, die Systeme auszuprobieren.