Gibt es etwas schnelleres als Pixels[x,y]:tColor?

[CPU-Quaeler]

@theo: Zur Frage, was wir erreichen wollen: Geschwindigkeitsvorteile! Im moment ist es so, dass z.b. die Berechnungs und Postprocessing-Threads auf einer 4-Kern-CPU nahezu perfekt skallieren (=>vier Threads=4mal so schnell fertig). Als Berechnungsergebnis entstehen bei 4 Threads und einer einzelnen zu zeichnenden Funktion 4 dyn. Arrays, deren Zeiger an den Mainthread zur Ausgabe übergeben wird. Und bisher wusste ich mir (wir uns) nicht anders zu helfen, als die Ergebnisse über den Pixels-Befehl zur Darstellung zu bringen. Das hat zur Folge, dass die Berechnung von 800000 Pixeln, einer Genauigkeit von 0,01(Pixel/Rechenschritt) und 64xAA in 800ms abgeschlossen ist (was vergleichsweise verdammt schnell ist), jedoch die Ausgabe dieser Pixel, die auch nur auf einem Kern gleichzeitig geht nochmal so viel Zeit draufschlägt (unnötigerweise, denn z.B. das Öffnen eines Bitmaps gleicher Größe ist in 20ms fertig).
Dass das langsam ist, und für jedes Pixel ein heiden-Aufwand getrieben wird, habe ich auch gemerkt, als ich mir angeschaut habe, was alles aufgerufen wird. Daher habe ich mich vertrauensvoll an euch gewendet und auch hilfreiche Tipps bekommen. Mir fehlt nur im Moment der Durchblick hinsichtlich der praktischen Umsetzung. Muss mich da erst durchkämpfen...nach der Arbeit ist das nicht mehr so leicht, wenn man den ganzen Tag geistig gefordert war.

Gruß, Arthur

[theo]

@Euklid: Hatten wir hier schon mal: http://www.lazarusforum.de/viewtopic.php?p=21251#p21251" onclick="window.open(this.href);return false;
Resultate in dem Vergleich damals:

OpBitmap Scanline : 190 ms
OpBitmap Pixels: 1669 ms
LazIntfImg: 5467 ms
TBitmap: 25515 ms

[Socke]

Vielleicht reicht es schon aus, wenn ihr mal das hier ausprobiert:

Code: Alles auswählen

var
  b: TRasterImage;
  i: PtrUInt;
begin
  b.BeginUpdate(True); // True = nur Canvas; False = auch andere Attribute (Höhe etc.)
  try
    // pixel bearbeiten
    b.RawImage.DataSize   // Byte-Anzahl
    b.RawImage.Data       // Pointer auf Daten
    b.RawImage.Description // Beschreibung der Pixel-Formate - WICHTIG!
  finally
    b.EndUpdate(False);
  end;
end;

Das kann man mit jedem TRasterImage (also Bitmap, PNG und was weiß ich noch alles) machen. Das b.RawImage bzw TRawImage ist auch noch recht gut in Lazarus-CCR dokumentiert (auch wenn ich nicht immer weiß, wie das ganze genau zu verstehen ist. Wahrscheinlich müsst ihr das bei eurem Vorhaben noch nicht mal benutzen.

[CPU-Quaeler]

Je mehr ich lese und versuche was zu tun, desto mehr Hindernisse ergeben sich.
Ich dreh am Rad. OpBitmap will nicht..siehe unten. LazIntfImage find ich zum Kotzen, weil ich jede Farbe einzeln zerpflücken darf (soweit ich das richtig verstanden habe) und die Farben auch noch "word"weise Komponenten haben.
@theo: Ich wollts ja mit OpBitmap ausprobieren....aber wie bekomme ich aus opBitmap wieder eine normale Bitmap, die ich anzeigen kann? Wenn ich AssignOpBitmapToBitmap(...) eingebe, dann bekomme ich nur lazbridge.pas(50,7) Error: identifier idents no member "AutoCreateMask".
@Socke: In welchem Kontext soll ich deinen Beitrag verstehen?? Und was ist mit der Variable "i"??

[theo]

dann bekomme ich nur lazbridge.pas(50,7) Error: identifier idents no member "AutoCreateMask".

Welche Version hast du denn erwischt?
Diese sollte es sein http://www.theo.ch/lazarus/opbitmap64.zip" onclick="window.open(this.href);return false;
opbitmapforlazcompat.lpk installieren (Oder auch nur die benötigten Files rauskopieren).

Es gibt auch noch schnellere Screen-Copy Methoden für 32bit Bilder als in Lazbridge.
Wenn du die brauchst, lass es mich wissen.

EDIT: Hab mal sowas hochgeladen. Auch für alphatransparentes Canvas Zeichnen. Win, GTK2, Qt.
http://www.theo.ch/lazarus/lazbridge32.zip" onclick="window.open(this.href);return false;

[mschnell]

Es handelt sich um die Canvas einer Bitmap (vom Typ tBitmap), die lokal erzeugt wird und nur im Arbeitsspeicher existiert.

TBitmap ist nicht im Arbeitsspeicher, sondern wird über den Grafiktreiber angesprochen, auch wenn das Bild gar nicht dargestellt wird (z.B. Off-Screen Picture im Grafik-Karten RAM) . Deshalb ist Pixel setzen sehr langsam, Gefüllte Flächen oder Texte erzeugen aber sehr schnell und ohne große Belastung der CPU, weil der Grafikprozessor das macht.

Wenn Du wirklich nur Pixel setzen willst, nimmst Du besser ein zweidimensionales Array of TColor im Memory, das von den Threads bearbeitet wird. ein Weiteter Thread kann das dann alle z.B. 200 msek auf dem Bildschirm darstellen (gibt es TBitmap.LoadFromStream oder so etwas ähnliches)

-Michael

[Euklid]

theo:
Ich habe die Diskussion deines OPBitmap-Projektes in den vergangenen Monaten (und Jahren) soweit wie mir möglich verfolgt, die Demo ausgeführt und stets positiv kommentiert. Trotzdem gibt es einige Fragen, die du vielleicht ausräumen könntest:

1. Die Lizenzpolitik des OPBitmap-Projektes war für mich immer schon ein Rätsel. Die verwendeten Komponenten stehen zumindest scheinbar alle unter einer unterschiedlichen Lizenz - zum einen ist es schwer, darüber den Überblick zu bewahren. Zu manchen Komponenten habe ich gar keine Lizenzen gefunden. Zum anderen ist die Lizenz auch deines Quelltextes für mich nicht deutlich genug geregelt. Außer einen Haftungsausschluss finde ich nichts. Daher: Unter welcher Lizenz stellst du deinen eigenen Quelltext der Welt zur Verfügung?
Verstehe mich nicht falsch, aber ich möchte meine Projekte veröffentlichen, ohne Lizenzprobleme zu bekommen. Und hier fehlt mir bei der OPBitmap zur Zeit die Transparanz.

2. Irgendwo hatte ich gelesen, dass die OPBitmap mit einer aktuelleren Lazarus-Version plötzlich nicht mehr lief. Was hat es damit auf sich? Bzw. inwiefern muss die OPBitmap an neue Lazarus-Versionen angepasst werden?

3. Wie sieht es mit der Unterstützung unterschiedlicher Architekturen aus? Hatte irgendwo gelesen, dass OPBitmap keinen Assembler-Code verwendet, was ja dafür sprechen würde. Nur suggerieren Bezeichnungen wie opbitmap64 zumindest eine Anpassung an bestimmte Architekturen.

Viele Grüße, Euklid

[theo]

1. Die Lizenzpolitik des OPBitmap-Projektes war für mich immer schon ein Rätsel.

Die Bilddatei-Leseformate sind tatsächlich aus verschiedenen Quellen und deshalb nicht einheitlich.
Der OpBitmap-Kern stammt aber von mir und ist frei. Man kann damit machen was man will.
Das ist ja der Teil, der euch hier interessieren würde.

Man sollte OpBitmap wie z.B. Synapse betrachten, nämlich so, dass man sich raus nimmt was man braucht, bzw. was ins Lizenz-Schema passt.
Es ist immer das gleiche:
- Wenn man kein Package macht, heisst es: Wo ist das Package?
- Wenn man ein Package macht, hiesst es: Ui, so ein grosses Package mit so vielen Dateien. Das möchte ich nicht...

2. Irgendwo hatte ich gelesen, dass die OPBitmap mit einer aktuelleren Lazarus-Version plötzlich nicht mehr lief. Was hat es damit auf sich? Bzw. inwiefern muss die OPBitmap an neue Lazarus-Versionen angepasst werden?

Bis auf die Lazbridge ist alles reines Object-Pascal. Es kompiliert grundsätzlich auch mit Delphi, Kylix.
Es ist also äusserst stabil. Die paar Fkt. in Lazbridge lassen sich leicht anpassen (war jetzt schon länger nicht mehr nötig).
In Lazbridge geht es ja nur drum, wie das OpBitmap auf einen Laz-Canvas kommt.
Da gibt es zig Möglichkeiten (hier die neue Variante von gestern Abend: http://www.theo.ch/lazarus/lazbridge32.zip" onclick="window.open(this.href);return false;).
Im undenkbaren, schlimmsten Fall kann man immer noch über BMP-Streaming Daten austauschen.
Man darf sich als Programmierer da auch einbringen. Mitdenken beseitigt irrationale Ängste

3. Wie sieht es mit der Unterstützung unterschiedlicher Architekturen aus? Hatte irgendwo gelesen, dass OPBitmap keinen Assembler-Code verwendet, was ja dafür sprechen würde. Nur suggerieren Bezeichnungen wie opbitmap64 zumindest eine Anpassung an bestimmte Architekturen.

Die 64-Bit Version soll auch auf Mac laufen, wurde mir berichtet.
Auch hier geht es weniger um den Kern als um die Bildleser. In der 64Bit Version sind die Graphic-Ex Formate ausgeschaltet.


Seht's doch mal pragmatisch: Anstatt mschnell's "Array of TColor im Memory," nehmt ihr einfach das blanke OpBitmap.
Da ist alles für den einfachen Zugriff schon vorbereitet (inkl , CopyRect, Resampling, Farbtiefenkonvertierung etc.) aber es ist eig. nichts anderes als ein Array of Pixel.
Hackt alles weg was ihr nicht braucht usw.

[mschnell]

Anstatt mschnell's "Array of TColor im Memory," nehmt ihr einfach das blanke OpBitmap.

Das hört sich doch gut an!
-Michael

[pluto]

Man sollte OpBitmap wie z.B. Synapse betrachten, nämlich so, dass man sich raus nimmt was man braucht, bzw. was ins Lizenz-Schema passt.

Das währe für mein Projekt nicht schlecht. Du meinst es währe Möglich einfach nur die "Dateien" die ich wirklich brauche herauszukopieren und zu verwenden ?
Z.B. wenn es mir um Alpha Blending geht oder aber auch: Ich habe in meinem Projekt eine TBitMap die ich als Hintergrund Buffer nutze, dass es leider erforderlich wegen dem Scrollen.
Wenn ich das richtig verstehe verwaltet OpBitmap einfach alles in einen Einfachen 2D Array und ist deshalb schneller als ein TBitMap.

In meinem Projekt kopiere ich sowieso alles aus dem Internen Buffer auf ein Canvas von einem TCustomControl. Daher könnte ich auch überall das OpBitMap Canvas Verwenden. Problem währe hierbei nur: Ich meine dein Canvas unterstützt keine TextOut, d.h. die Objekte müssten also zwei Canvas Variablen haben, sehe ich das richtig ?

Im Moment bin ich noch am überlegen ob ich mein Projekt auf AggPas umstellen sollte. Das Was mich bei OpBitmap Stört ist einfach noch das der Canvas nicht so viel kann. Anderen Seits stelle ich mir das auch unmöglich vor, dass es eingebaut werden kann, z.b. eine TextOut Funktion.

[theo]

Du meinst es währe Möglich einfach nur die "Dateien" die ich wirklich brauche herauszukopieren und zu verwenden?

Klar

Wenn ich das richtig verstehe verwaltet OpBitmap einfach alles in einen Einfachen 2D Array

Ein 1D Array.

dass es eingebaut werden kann, z.b. eine TextOut Funktion.

OpBitmap ist für schnelle Pixelmanipulationen gedacht. TextOut etc. wird es voraussichtl. nicht geben.

[pluto]

OpBitmap ist für schnelle Pixelmanipulationen gedacht. TextOut etc. wird es voraussichtl. nicht geben.

Genau da sehe ich für mein Projekt das Problem. Also müsste ich mir was eigenen erstellen....

[Socke]

Mein Beitrag bezog sich auf das Ändern eines TRasterImage (davon sind alle gängigen Implementationen für Rastergrafiken also auch TBitmap abgeleitet). Da ich mich damit aber noch nicht tief gehend beschäftigt habe, Verweise ich auf die Dokumentation der LCL (alles was ich dazu sage, beziehe ich auch nur ausschließlich daher).

Wenn man Bilder direkt bearbeiten will (d.h. im Speicher), kann man das über TRasterImage.RawImage.Data tun. Dazu muss man das Pixelformat und was weiß ich noch alles wissen (evtl. auch das Dateiformat). Die Variable i stammt von einer geplanten, aber nicht realisierten Beispieliteration über den gesamten Speicherbereich. So kann man ohne Abhängigkeit des Widgetsets das Bild verändern (auch wenn man ohne Widgetset wahrscheinlich nicht compilieren kann). Einen 1D-Array von Pixelwerten könnte man also auch hier abbilden (ich weiß aber nicht, inwiefern TRawImage die Bild-Rohdaten oder die -Rohdatei verwaltet).

Alle Zeichenoperationen über TRasterImage.Canvas werden vom Widgetset ausgeführt. Inwiefern Begin-/EndUpdate Einfluss auf das Neuzeichnen der Benutzeroberfläche hat, kann ich nicht beurteilen.

[mschnell]

Alles auf einmal geht eben nicht

Text ist schnell mit dem Grafik-Karten Prozessor (in dessen RAM) , viele einzelne Pixel setzen ist schnell mit der PC-CPU (in deren RAM). Datenaustausch zwischen diesen RAMs ist langsam. Wenn Du beides auf einmal brauchst wird's langsam und/oder kompliziert.

-Michael

[Euklid]

theo: Danke für die Aufklärung!

D.h. dein Quelltext ist sozusagen public domain. Finde ich gut.