Schnellstmöglich auf den Bildschirm zeichnen

[400kmh]

Hallo,

ich möchte möglichst viele Dinge auf dem Bildschirm in möglichst kurzen Zeitintervallen zeichnen. Ich habe das bisher mit Canvas gemacht, aber scheint sehr langsam zu sein. Da geht zwar schon einiges mit, aber so in der Größenordnung von geschätzt 5.000-125.000 Dreiecken pro Sekunde wird es halt schwierig. Computer sind heute aber offensichtlich zu wesentlich mehr in der Lage, also muss es an der Programmierung liegen.

Was sind die schnellsten und einfachsten Möglichkeiten
- einen Punkt auf dem Bildschirm zu zeichnen (z. B. Rot an der Stelle x=15, y=135 des Bildschirms)?
- ein Dreieck auf dem Bildschirm zu zeichnen (z. B. Blau zwischen den Punkten (x=12,y=50),(x=102,y=24),(x=38,y=69))?

Gibt es Möglichkeiten direkt auf den Bildschirm zuzugreifen?

Früher habe ich mal was mit Unit Graph gemacht, das kam ohne Canvas-Gedöns aus, war aber, wenn ich mich recht erinnere, noch langsamer, aber da habe ich es möglicherweise nur zu kompliziert gemacht.

[Socke]

Schnell geht das nur, wenn du den Grafikprozesse nutzt. Dazu kannst du z.B. openGL machen.

[400kmh]

Schnell geht das nur, wenn du den Grafikprozesse nutzt. Dazu kannst du z.B. openGL machen.

Wie kann ich denn OpenGL benutzen und damit ein Dreieck zeichnen?

Und was ist hiermit: https://wiki.freepascal.org/Fast_direct_pixel_access Nutzt das auch keine Grafikprozesse?

Wenn OpenGL Grafikprozesse nutzen kann, warum kann das Lazarus nicht selbst?

[u-boot]

Wenn OpenGL Grafikprozesse nutzen kann, warum kann das Lazarus nicht selbst?

Ich glaube die richtige Antwort auf diese Frage liegt irgendwo neben "Weil du es noch nicht (plattformübergreifend) implementiert hast"

[400kmh]

Ich glaube die richtige Antwort auf diese Frage liegt irgendwo neben "Weil du es noch nicht (plattformübergreifend) implementiert hast"

Also ich habe keinen Plan was genau das Problem ist. Das Plattformübergreifende? Die Implementierung? Mit Bitmap.Canvas.Pixels kann man doch einfach Pixel zeichnen, aber warum geht es nicht schneller? Ist das ein Lazarus-spezifisches, Pascal-spezifisches oder ein allgemeines Problem beim Programmieren in allen Programmiersprachen?

Mit Pascal komme ich eigentlich gut zurecht. Habe es damals in der Schule ein Jahr lang gehabt und danach eigenbrötlerisch Sachen programmiert. Aber ich muss halt immernoch Einsteigerfragen stellen, da ich vieles nie gelernt habe.

[mschnell]

Die Grafik-Hardware kann keine Pixel verwalten, sondern nur Grafik-Objekte. Ein komplexes Objekt zu zeichen ist nicht viel langsamer als einen einzelnen Pixel.
-Michael

[Michl]

Das Zeichnen per Canvas ist deshalb recht langsam, da jeder Zugriff per Canvas letztlich die System-API aufruft.

Schneller geht es, wenn man nur im Speicher zeichnet und das fertige Bild im OnPaint-Event aufs Canvas kopiert. Recht hübsch ist z.B. das Fading-Beispiel: https://wiki.freepascal.org/Developing_ ... ng_example

Wie Socke schon schrieb, wenn es noch schneller gehen soll, dann nimm OpenGL. Da gibt es die unterschiedlichsten Bibliotheken, die das unterstützen: https://wiki.freepascal.org/Developing_ ... s#See_also

Das hatte ich mal per BGRABitmap getestet - geht recht unkompliziert zu verwenden - und man kann sogar einen kleinen Contest damit gewinnen
https://forum.lazarus.freepascal.org/in ... #msg214556
https://forum.lazarus.freepascal.org/in ... #msg212079
Weitere Infos dazu: https://wiki.freepascal.org/BGRABitmap_and_OpenGL

[400kmh]

Danke für die Antworten.

Die Grafik-Hardware kann keine Pixel verwalten, sondern nur Grafik-Objekte.

Heißt das, da ist alles grundsätzlich in 3D, oder gibts da auch 2D-Objekte nur bloß keine Punkte und Strecken, also Objekte ohne Fläche? Wie löst man es dann, wenn man im Hintergrund etwas in 3D zeichnen will und im Vordergrund etwas in 2D ohne definierte Flächen?

Ein komplexes Objekt zu zeichen ist nicht viel langsamer als einen einzelnen Pixel.

Ja, das habe ich schon gemerkt. Ich hatte mal angefangen so eine "FastBitmap" zu programmieren, da kam FillDWord vor:

Code: Alles auswählen

  procedure TFastBitmap.Spalte(X, Y1, Y2: Integer); inline;
  var
    P: ^TColor;
  begin
    P := @Pixels[x,y1];
    FillDWord(P^, abs(Y2-Y1)+1, Farbe);
  end;

Eine Spalte füllen geht damit quasi genauso schnell wie einen Pixel zu füllen.

Insgesamt war meine Erfahrung mit FastBitmap, dass kleine Dreiecke viel schneller gezeichnet wurden als mit normaler Bitmap, bei großen Dreiecken war der Unterschied niedriger. Bei der Übernahme in mein Hauptprojekt gab es dann allerdings ein paar Probleme z. B. mit den Farben und der Geschwindigkeitsvorteil war nicht so extrem, sodass ich daran gezweifelt habe, ob das der große Wurf ist. Aber vielleicht sollte ich das einfach weiterverfolgen.

Das Zeichnen per Canvas ist deshalb recht langsam, da jeder Zugriff per Canvas letztlich die System-API aufruft.

Schneller geht es, wenn man nur im Speicher zeichnet und das fertige Bild im OnPaint-Event aufs Canvas kopiert. Recht hübsch ist z.B. das Fading-Beispiel: https://wiki.freepascal.org/Developing_ ... ng_example

Hört sich zunächst mal nach der Lösung des gesamten Problems an. Mal sehen ob ich das hinbekomme.

Einem Array Farben zuordnen und ihn dann möglichst als Ganzes auf einmal von der Bildschirmausgabe übernehmen. Aber OpenGL wäre dann trotzdem noch schneller?

[wp_xyz]

ich möchte möglichst viele Dinge auf dem Bildschirm in möglichst kurzen Zeitintervallen zeichnen. Ich habe das bisher mit Canvas gemacht, aber scheint sehr langsam zu sein. Da geht zwar schon einiges mit, aber so in der Größenordnung von geschätzt 5.000-125.000 Dreiecken pro Sekunde wird es halt schwierig.

"Möglichst viele Dinge in möglichst kurzen Zeitintervallen" ist eine sehr pauschale Aussage, aber 5.000-125.000 Dreiecke pro Sekunde ist dann doch eine Orientierungsgröße. Und die Aussage "Canvas scheint sehr langsam zu sein" ist auch wieder sehr pauschal.

Ich wollte es dann wissen und habe ein kleines, nicht-optimiertes Testprogramm geschreiben. Es werden 10.000 zufällige Dreiecke in zufälligen Farben mit verschiedenen Verfahren gezeichnet und ich messe die dafür benötigte Zeit.

Zunächst der Canvas. Ich male die Dreiecke direkt in der OnPaint-Methode eines Panels. Dabei schafft der Canvas auf meinem Rechner 60.000 Dreiecke pro Sekunde. Als "sehr langsam" würde ich das nicht bezeichnen.

Da das Bild auf dem Panel wegen der Zufallszahlen und der Bildentstehung im OnPaint-Ereignis nicht persistent ist (d.h. wenn ich ein anderes Fenster über das Panel ziehe, wird das Bild mit anderen Dreiecken neu gezeichnet), habe ich als nächstes versucht, zunächst in ein Bitmap zu zeichnen und dieses dann im OnPaint-Ereignis auf den Canvas zu kopieren. Da schaffe ich nur 24.000 Dreiecke pro Sekunde, offenbar kostet das Umkopieren auf den Canvas einen nennenswerten Anteil der Laufzeit (ich hätte nicht so viel erwartet, und vielleicht habe ich ja auch etwas falsch gemacht).

Dritter Versuch: Nach meiner Erfahrung ist das LazIntfImage schneller als der Canvas. Ich male in einem LazIntfImage, das in ein Bitmap umgewandelt und auf den Canvas kopiert wird. 40.000 Dreiecke pro Sekunde, aber offenbar ist die Hinundherkopiererei doch ganz schön aufwendig. Auch habe ich es nicht hingekriegt, dass die Dreiecke farbig gefüllt werden. Zum Vergleich habe ich dann statt Dreiecken Rechtecke genommen, und da bricht die Leistung auf ein paar Hundert Rechtecke pro Sekunde ein. Offenbar ist der FPImage-Canvas für solche Operationen gar nicht optimiert (oder ich habe einen riesenfehler gemacht, was auch gut sein kann).

Letzter Versuch: OpenGL. Ich bin da zwar kein Spezialist, aber ich habe dann auch einen testlauf in orthographischer Projektion (2D) hinbekommen. Es wird auch immer direkt auf das OpenGLcontrol gemalt, also ohne einen Umweg über ein Buffer-Bitmap. Da schafft der erste Aufruf etwas mehr als der direkte Canvas-Aufruf (70.000), die nachfolgenden sind dann rasend schnell mit 2-3 Millionen Dreiecken pro Sekunde.

Wiegesagt, das alles ist sehr quick and dirty zusammengeklickt, man kann das sicher noch optimieren. Einen Versuch wäre auch BGRABitmap wert. Aber damit habe ich noch nichts gemacht, und vielleicht liefert das ja jemand nach.

Fazit: Also SOOOO schlecht ist der Canvas auch wieder nicht.

[Maik81SE]

Da hab ich passend oder vielleicht auch unpassend eine Frage.

Der PI4 hat ja wenn ich das richtig auf dem Film habe, keinen Eigenen Grafikprozessor oder etwa doch

Das hatte ich mal per BGRABitmap getestet - geht recht unkompliziert zu verwenden - und man kann sogar einen kleinen Contest damit gewinnen
https://forum.lazarus.freepascal.org/in ... #msg214556
https://forum.lazarus.freepascal.org/in ... #msg212079
Weitere Infos dazu: https://wiki.freepascal.org/BGRABitmap_and_OpenGL

Da könnte ich mir hierbei eventuell VIEL arbeit und aufwand sparen...

[Socke]

Der PI4 hat ja wenn ich das richtig auf dem Film habe, keinen Eigenen Grafikprozessor oder etwa doch

Der SoC (System-on-Chip) BCM2711 hat einen integrierten Grafikprozessor mit dem Namen "VC6". Der kann auch OpenGL ES 3.0.

[Frank Ranis]

Hallo ,

schau dir mal das Partikel-Schwarm-Tutorial von Daniel Schwamm an.

http://www.daniel-schwamm.de/index.php? ... telligence

Sehr geil , OpenGL , viele Fischlein als Dreiecke dargestellt im 3D Raum.
Ganz unten auf der Seite sind auch ein paar Filme.

Ich habe das Programm von Delphi nach LAZ portiert und es funzt unter WIN und LINUX.

Wenn Du dir dir Mühe machst und Kontakt mit Daniel aufnimmst und er mir sein OK für eine Veröffentlichung hier im Forum gibt , dann lade ich die Lazarus-Version hier hoch.

Oder Du lädst dir einfach die Quellen und machst die Portierung selber.
Basis ist Delphi7 , das funzt noch prima für die Portierung.

Der Daniel hat noch viele andere Leckerchen auf seiner Seite , ein Besuch lohnt sich.

Gruß

Frank

[Maik81SE]

Der PI4 hat ja wenn ich das richtig auf dem Film habe, keinen Eigenen Grafikprozessor oder etwa doch

Der SoC (System-on-Chip) BCM2711 hat einen integrierten Grafikprozessor mit dem Namen "VC6". Der kann auch OpenGL ES 3.0.

Oha...
Auch noch mein Lieblingschip
gerade die truppe, die nahezu überall eingebaut wird, aber wo Ubuntu arg trupple macht, zumindest auf meinen beiden. Systemen was W-Lan angeht...
Aber das werd iich mir mal mit anschauen, was er mir im Bereich Video rauswerfen kann.
also brauche ich noch OpenGL

[400kmh]

"Möglichst viele Dinge in möglichst kurzen Zeitintervallen" ist eine sehr pauschale Aussage, aber 5.000-125.000 Dreiecke pro Sekunde ist dann doch eine Orientierungsgröße. Und die Aussage "Canvas scheint sehr langsam zu sein" ist auch wieder sehr pauschal.

Kommt halt darauf an womit man es vergleicht. Mal ein Gedankenspiel: In einem modernen Computerspiel hat quasi jeder Pixel eine eigene Farbe durch Belichtung, Nebel, Kantenglättung etc. Dann werden die mit z. B. 100 FPS angezeigt. Bei einer Auflösung von z. B. 1600*900 macht das dann 144.000.000 Pixel pro Sekunde. Verglichen damit ist 5.000-125.000 halt ziemlich wenig. Aber für bestimmte Anwendungen kann Canvas dennoch locker ausreichen.

Ich wollte es dann wissen und habe ein kleines, nicht-optimiertes Testprogramm geschreiben. Es werden 10.000 zufällige Dreiecke in zufälligen Farben mit verschiedenen Verfahren gezeichnet und ich messe die dafür benötigte Zeit.

Welche Fläche haben die Dreiecke?

Das scheint mir wichtig zu sein.

Ich habe jetzt mal mit meiner FastBitmap und Canvas einen Test für unterschiedliche große Quadrate gemacht:

Meine FastBitmap schafft
- bei 2x2 großen Quadraten etwa 1.250.000 Quadrate pro Sekunde.
- bei 4x4 großen Quadraten etwa 850.000 Quadrate pro Sekunde.
- bei 16x16 großen Quadraten etwa 300.000 Quadrate pro Sekunde.
- bei 64x64 großen Quadraten etwa 40.000 Quadrate pro Sekunde.
- bei 256x256 großen Quadraten etwa 3.000 Quadrate pro Sekunde.

Canvas schafft bei mir
- bei 2x2 großen Quadraten etwa 35.000 Quadrate pro Sekunde.
- bei 4x4 großen Quadraten etwa 35.000 Quadrate pro Sekunde.
- bei 16x16 großen Quadraten etwa 30.000 Quadrate pro Sekunde.
- bei 64x64 großen Quadraten etwa 27.000 Quadrate pro Sekunde.
- bei 256x256 großen Quadraten etwa 6.000 Quadrate pro Sekunde.

Also bei kleinen Quadraten (und bei Dreiecken ist das nicht anders), hat meine FastBitmap einen großen Vorteil, aber bei großen Quadraten gerät sie sogar leicht ins Hintertreffen. Da scheint Canvas etwas zu können, was meine FastBitmap nicht kann.

Hier ein paar Teile des Codes, hoffe die Funktionsweise der FastBitmap erklärt sich dadurch:

Code: Alles auswählen

  TFastBitmap = class
    Procedure Spalte(X, Y1, Y2: Integer);
    Procedure Linie(Integer1, Integer2, Integer3, Integer4: Integer);
    Procedure Rechteck(Integer1, Integer2, Integer3, Integer4: Integer);
    Procedure Dreiecksflaeche(Point1, Point2, Point3: TPoint);
    Procedure Dreieck(Point1, Point2, Point3: TPoint);
    Procedure Viereck(Point1, Point2, Point3, Point4: TPoint);
    Procedure Fuenfeck(Point1, Point2, Point3, Point4, Point5: TPoint);
  private
    function GetSize: TPoint;
    procedure SetSize(const AValue: TPoint);
  public
    Farbe: TColor;
    Pixels: array of array of TColor;
    property Size: TPoint read GetSize write SetSize;
  end; 
  
  [...]
  
  procedure FastBitmapToBitmap(FastBitmap: TFastBitmap; Bitmap: TBitmap);
var
  X, Y: Integer;
  PixelPtr: PInteger;
  PixelRowPtr: PInteger;
  RawImage: TRawImage;
  BytePerPixel: Integer;
begin
  try
    Bitmap.BeginUpdate(False);
    RawImage := Bitmap.RawImage;
    PixelRowPtr := PInteger(RawImage.Data);
    BytePerPixel := RawImage.Description.BitsPerPixel div 8;
    for Y := 0 to FastBitmap.Size.Y - 1 do begin
      PixelPtr := PixelRowPtr;
      for X := 0 to FastBitmap.Size.X - 1 do begin
        PixelPtr^ := FastBitmap.Pixels[X, Y];
        Inc(PByte(PixelPtr), BytePerPixel);
      end;
      Inc(PByte(PixelRowPtr), RawImage.Description.BytesPerLine);
    end;
  finally
    Bitmap.EndUpdate(False);
  end;
end;

procedure TFastBitmap.Spalte(X, Y1, Y2: Integer); inline;
var
  P: ^TColor;
begin
  P := @Pixels[x,y1];
  FillDWord(P^, abs(Y2-Y1)+1, Farbe);
end;      

Procedure TFastBitmap.Rechteck(Integer1, Integer2, Integer3, Integer4: Integer); inline;
var
  Zaehler1, Zaehler2: Integer;
  x1, x2, y1, y2: Integer;
begin
  if Integer1<=Integer3 then begin
    x1:=Integer1;
    x2:=Integer3; end else
  begin
    x1:=Integer3;
    x2:=Integer1; end;
  if Integer2<=Integer4 then begin
    y1:=Integer2;
    y2:=Integer4; end else
  begin
    y1:=Integer4;
    y2:=Integer2; end;

  if x1<0 then x1:=0;
  if y1<0 then y1:=0;
  if x2>=Size.x then x2:=Size.x-1;
  if y2>=Size.y then y2:=Size.y-1;

  for Zaehler1:=x1 to x2 do
    Spalte(Zaehler1, y1, y2);
end;  

[...]
  
FastBitmapToBitmap(FastBitmap1, Bitmap);
Form1.Canvas.Draw(0,0,Bitmap);  

Dafür habe ich mir vieles hier abgeguckt: https://wiki.freepascal.org/Fast_direct_pixel_access

Vielleicht Gibts da noch Optimierungspotenzial. Dass Canvas bei großen Flächen besser ist, ist z. B. ein klares Manko.

Letzter Versuch: OpenGL. Ich bin da zwar kein Spezialist, aber ich habe dann auch einen testlauf in orthographischer Projektion (2D) hinbekommen. Es wird auch immer direkt auf das OpenGLcontrol gemalt, also ohne einen Umweg über ein Buffer-Bitmap. Da schafft der erste Aufruf etwas mehr als der direkte Canvas-Aufruf (70.000), die nachfolgenden sind dann rasend schnell mit 2-3 Millionen Dreiecken pro Sekunde.

Hört sich vielversprechend an.

Wiegesagt, das alles ist sehr quick and dirty zusammengeklickt, man kann das sicher noch optimieren. Einen Versuch wäre auch BGRABitmap wert. Aber damit habe ich noch nichts gemacht, und vielleicht liefert das ja jemand nach.

Aber welchen Vorteil hätte das gegenüber der "FastBitmap"?

[wp_xyz]

Kommt halt darauf an womit man es vergleicht. Mal ein Gedankenspiel: In einem modernen Computerspiel hat quasi jeder Pixel eine eigene Farbe durch Belichtung, Nebel, Kantenglättung etc. Dann werden die mit z. B. 100 FPS angezeigt. Bei einer Auflösung von z. B. 1600*900 macht das dann 144.000.000 Pixel pro Sekunde. Verglichen damit ist 5.000-125.000 halt ziemlich wenig. Aber für bestimmte Anwendungen kann Canvas dennoch locker ausreichen.

Natürlich. Aber die 5.000-125.000 stammen von dir. Und das ist mit Canvas zu schaffen. Wenn dein Ziel höher liegt, warum nennst du dann diese Zahlen?

Welche Fläche haben die Dreiecke? Das scheint mir wichtig zu sein.

Ja. Das Panel, auf dem gezeichnet wird, ist 1043x576 groß und die Dreiecke werden darin durch jeweils drei Paare von Zufallszahlen bestimmt.

Ich habe jetzt mal mit meiner FastBitmap und Canvas einen Test [...] gemacht

Natürlich ist FastBitmap schneller als Canvas, keine Frage. Es ist halt immer eine Frage der Anforderung. Nur weil es schneller ist, würde ich FastBitmap nie nehmen, wenn ich die Geschwindigkeit nicht braucht, denn ich handle mir dadurch die Abhängikeit von einer evtl. verwaisten Bibliothek ein. Was nützt mir die schnellste Graphik-Bibliothek, wenn mein Lazarus nach dem Update auf die neue Version nicht mehr startet, weil sich niemand um nun plötzlich in ihr auftauchende Fehler kümmert?

Aber welchen Vorteil hätte das (OpenGL) gegenüber der "FastBitmap"?

Dass die Graphik von der Graphik-Karte gezeichnet wird