GDI, GDI+ oder doch Direct2D?

[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 von Memnarch:

@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

[implementation]

[OT]

Zitat von rollstuhlfahrer:

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

[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

[Thom]

Zitat von rollstuhlfahrer:

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 von Thom:

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 von rollstuhlfahrer:

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

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;