Schnellstmöglich auf den Bildschirm zeichnen

Für Fragen von Einsteigern und Programmieranfängern...
400kmh
Beiträge: 100
Registriert: Do 25. Mär 2010, 04:03

Re: Schnellstmöglich auf den Bildschirm zeichnen

Beitrag von 400kmh »

wp_xyz hat geschrieben: 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?
Ich habe diese Zahlen genannt, weil da irgendwo die Grenze liegt. Ich würde gern mehr machen, aber das mache ich zur Zeit eben nicht, weil es zu Verlangsamung führt.
wp_xyz hat geschrieben:Dass die Graphik von der Graphik-Karte gezeichnet wird
Das war auf BGRABitmap bezogen.

Wenn ich es richtig verstehe, funktionieren weder LazIntfImage noch BGRABitmap mit Grafikkarte. FastBitmap ist halt was selbst programmiertes ebenfalls ohne Grafikkarte und ich weiß nicht ob LazIntfImage und BGRABitmap irgendwelche Vorteile gegenüber FastBitmap haben. Auf der anderen Seite ist selbst Canvas bei großen Flächen etwas besser als meine FastBitmap. Irgendwie kann man wohl auch ohne Grafikkarte größere Flächen noch etwas schneller mit einer Farbe füllen. Bei Kleinstflächen scheint meine FastBitmap hingegen schon näher an Grafikkarten heranzukommen.

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: Schnellstmöglich auf den Bildschirm zeichnen

Beitrag von wp_xyz »

400kmh hat geschrieben:
Do 21. Jan 2021, 15:37
[Wenn ich es richtig verstehe, funktionieren weder LazIntfImage noch BGRABitmap mit Grafikkarte.
"Funktionieren" tun sie schon, aber sie arbeiten im RAM und die CPU berechnet z.B. bei einem Polygon-Fill wie die Schnittpunkte mit den Polygonkanten liegen. OpenGL macht das gleich in Graphik-Spwicher und mit der auf paralleles Arbeiten optimierten GPU.
400kmh hat geschrieben:
Do 21. Jan 2021, 15:37
FastBitmap ist halt was selbst programmiertes ebenfalls ohne Grafikkarte und ich weiß nicht ob LazIntfImage und BGRABitmap irgendwelche Vorteile gegenüber FastBitmap haben.
Objektiv gesehen wahrscheinlich nicht. LazIntfImage gehört zu Lazarus - keine Zusatzbibliothek nötig. BGRABitmap wird aktiv weiterentwickelt, ist aber natürlich von dem (einen) Entwickler abhängig. Wie geht's weiter, wenn der mal sagt, ok, jetzt reichts...? Andererseits, wenn FastBitmap deine Arbeit ist hast du alles in der Hand, muss aber auch alles selbst machen.
400kmh hat geschrieben:
Do 21. Jan 2021, 15:37
Auf der anderen Seite ist selbst Canvas bei großen Flächen etwas besser als meine FastBitmap.
Da würde ich nach einem Test nicht unbedingt drauf schwören.
400kmh hat geschrieben:
Do 21. Jan 2021, 15:37
Bei Kleinstflächen scheint meine FastBitmap hingegen schon näher an Grafikkarten heranzukommen.
Wenn du dich da auf meinen Vergleichstest beziehst: Ich bin kein Spieler und habe nur die Prozessor-Graphik. Echte Graphik-Karten sind vermutlich viel schneller.

Wenn du eine sehr schnelle Graphikausgabe brauchst (wofür auch immer), führt keine Weg an OpenGL vorbei. Ist natürlich eine gewisse Lernkurve, aber Mathias hier im Forum kennt sich damit aus.

marcov
Beiträge: 1100
Registriert: Di 5. Aug 2008, 09:37
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
CPU-Target: 32/64,PPC(+64), ARM
Wohnort: Eindhoven (Niederlande)

Re: Schnellstmöglich auf den Bildschirm zeichnen

Beitrag von marcov »


mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Schnellstmöglich auf den Bildschirm zeichnen

Beitrag von mschnell »

Socke hat geschrieben:
Mi 20. Jan 2021, 17:46
Der SoC (System-on-Chip) BCM2711 hat einen integrierten Grafikprozessor mit dem Namen "VC6".
Sonst wäre der Raspi für normale GUI-Anwendungen auch viel zu langsam und ungeeignet.
-Michael

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Schnellstmöglich auf den Bildschirm zeichnen

Beitrag von mschnell »

wp_xyz hat geschrieben:
Do 21. Jan 2021, 16:24
Echte Graphik-Karten sind vermutlich viel schneller.
Bei 3-D Animationen (Ray Tracing) und ähnlichem.
-Michael

400kmh
Beiträge: 100
Registriert: Do 25. Mär 2010, 04:03

Re: Schnellstmöglich auf den Bildschirm zeichnen

Beitrag von 400kmh »

In der Zwischenzeit habe mich mal einiges ausprobiert:

- OpenGL: Ist ziemlich umständlich und merkwürdig. Mehrere OpenGLControls gehen nicht. Beim Übernehmen des OpenGL-Bildes mit einer Bitmap wird Rot und Blau vertauscht. Oben und Unten ebenso. Width und Height von OpenGLControl lassen sich nicht zur Laufzeit ändern (Änderung wird einfach ignoriert.). X und Y-Paramenter der Pixel können nicht direkt übergeben werden, sondern müssen in relative Positionen umgerechnet werden. Bei OpenGLControl.Hide wird nichts mehr gezeichnet, das heißt man braucht ein eignes Fenster im Hintergrund für OpenGL, wenn man es im Hintergrund laufen lassen will. Das sind alles Probleme die vielleicht irgendwie lösbar/verbesserbar sind, aber vor allem scheint OpenGL auch nicht schneller zu sein. Vielleicht liegts am Kopieren auf die Bitmaps, was aber nötig zu sein scheint, wenn man mehrere Bilder gleichzeitig haben will. Oder vielleicht ist OpenGL nur bei 3D-Berechnungen schneller.

-Assembler: Habe Alternativen zu FillDWord in Assembler im Internet gefunden. Ist aber nur bei langen Füllungen schneller. Bei kurzen ist FillDWord schneller. Unter dem Strich kein Vorteil. Vielleicht nützt es aber etwas die Berechnung der Schnittpunkte der Zeilen mit den Dreiecks-Kanten in Assembler zu programmieren.

- Anstatt Dreiecke erst auf eine FastBitmap zu schreiben und diese dann mit dem Rawimage der Bitmap zu übernehmen, habe ich jetzt eine Prozedur geschrieben, die die Dreiecke direkt mit FillDWord auf das RawImage der Bitmap schreibt. Das ist tatsächlich schneller, womit ich erstmals in der praktischen Anwendung einen leichten Geschwindigkeitsvorteil feststellen konnte. Zudem ist diese Prozedur mit den Canvas-Prozeduren kompatibel, d. h. die Prozeduren können miteinander abgewechselt werden, und beide werden gezeichnet. Eine leichte Verbesserung aber nicht wirklich der große Wurf bislang.

- Beim Vergleich mit herkömmlichen Canvas-Funktionen ist mir aufgefallen, dass beim manuellen reinschreiben von TColor-Werten ins RawImage die Werte von Rot und Blau vertauscht sind (wie bei OpenGL), was auch bei genauerer Betrachtung ziemlich merkwürdig ist. Zunächst habe ich gedacht, dass die Daten vielleicht um 1-3 Byte verschoben wären, also habe ich versucht sie verschoben in das RawImage zu schreiben (was das Problem nicht gelöst hat: R und B sind einfach vertauscht). Dabei ist mir aufgefallen, dass das ein leeres Byte zwischen zwei BGR-Abschnitten von Canvas.Draw offensichtlich als Alpha-Kanal für Transparenz verwendet wird. Frage dazu: Greift Canvas.Draw auf die Grafikkarte zu? Denn das Transparent-Zeichnen scheint vergleichsweise effizient zu sein. Das bringt mich auf die Idee, das vielleicht das Übereinander-Drawen vieler einfarbig gefüllter Bitmaps mit transparenten Abschnitten schneller sein könnte als das direkte Zeichnen von allem auf eine Bitmap. Die transparenten Abschnitte müssten jeweils nur eine einfache Definition haben (was in meinem Fall überwiegend gegeben sein könnte), und man brächte passende Prozeduren. Dazu müsste ich zwar recht viel umschreiben in meinem Programm, aber Potenzial sehe ich da unter Umständen, je nachdem wie schnell Canvas.Draw wirklich ist.

Benutzeravatar
Winni
Beiträge: 1577
Registriert: Mo 2. Mär 2009, 16:45
OS, Lazarus, FPC: Laz2.2.2, fpc 3.2.2
CPU-Target: 64Bit
Wohnort: Fast Dänemark

Re: Schnellstmöglich auf den Bildschirm zeichnen

Beitrag von Winni »

Hallo

Wenn Du mit Intel-Prozessor arbeitest (und kompatiblen) dann sind die Bytes vertauscht, außerdem HiWord und LowWord in einem DWord.

Die Byte-Reihenfolge in TColor ist also

Null-Blau-Grün-Rot

Beschwer Dich bitte bei Intel über diesen Design-Bolzen

Winni

Antworten