Benchmark Test bzw ein Versuch dazu^^

[theo]

Lieber ein gepflegtes Zip als eine verwaiste SVN

[Euklid]

Bestehen Pläne, die OPbitmap.pas eines Tages in das Lazarus-Projekt zu integrieren? Bzw. was spricht nach deiner Auffassung dagegen?

[Christian]

OPBitmap ersetzt ja funktionalität vom lazarus, ich glaube kaum das die Kern Entwickler da mitspielen würden. Die lassen sicher lieber ihre eigenen Sachen im Lazarus.

[theo]

Bestehen Pläne, die OPbitmap.pas eines Tages in das Lazarus-Projekt zu integrieren? Bzw. was spricht nach deiner Auffassung dagegen?

Nein. Dafür ist es zu spezialisiert und ersetzt auch weder TBitmap noch TLazInftImage. Im Gegenteil, es benötigt diese in lazbridge auch zur betriebssystemspezifischen Umwandlung und zur Anzeige. Also kommt bitte mal von diesem Entweder-Oder Denken weg.

OpBitmap ist ein weitgehend Delphi TBitmap kompatibles In-Memory Bitmap für schnelle Pixelmanipulationen.
Es kann Pixelformate selbständig und ohne X, GDI etc umwandeln inkl Farbquantisierung und Paletten, das macht TBitmap (notgedrungen) nicht, da dieses am Device angebunden ist.

Durch die Delphi Kompatibilität (Scanline, Pixelformat, Paletten) ist es praktisch ohne Aufwand möglich, die grosse Anzahl vorhandener Delphi Codes zum Image Processing wiederzuverwenden.

OpBitmap läuft ohne X-Server, benötigt keine GDI-Ressourcen und macht keine Probleme beim Multithreading, z.B. um einen Server oder ein Apache Modul zu schreiben welche multithreaded Bilder konvertieren.

OpBitmap kann nur via TBitmap Bilder auf den Screen bringen.
Dafür ist es für andere Sachen, wie z.B. Batch-Processing von Bilddateien dramatisch viel schneller und praktischer.

Also Schwarz-Weiss denken ist nicht angesagt.
OpBitmap ist es weder schlechter noch besser als TBitmap.
OpBitmap ist es weder schlechter noch besser als TLazintfimage.
TBitmap ist es weder schlechter noch besser als TLazintfimage.

Das ist alles was anderes!

[Euklid]

Ich halte Opbitmap als etwas sehr nützliches und grundlegend verschiedenes zu TBitmap, TLazintfimage gesehen, daher stellte sich ja die Frage. Denn gäbe es eine vergleichbare Komponente integriert in Lazarus, würde meine obige Frage wenig Sinn machen.

Es ist also nicht so schwarz-weiß gemeint gewesen, wie es aufgefasst wurde.

[theo]

Es ist also nicht so schwarz-weiß gemeint gewesen, wie es aufgefasst wurde.

Das war auch nicht auf deinen Beitrag gemünzt, sondern es wird generell in diesem Thread etwas oberflächlich lamentiert, statt sich die Mühe zu nehmen, die Ansätze zu verstehen.

Ich halte Opbitmap als etwas sehr nützliches und grundlegend verschiedenes zu TBitmap, TLazintfimage gesehen, daher stellte sich ja die Frage. Denn gäbe es eine vergleichbare Komponente integriert in Lazarus, würde meine obige Frage wenig Sinn machen.

Es gibt noch eine andere Antwort darauf:
Wenn man mit Opbitmap nur die Datei opbitmap.pas mit support-units sowie allenfalls lazbridge meint, könnte man es theoretisch als Lösung für spezielle Probleme integrieren. opbitmap.pas würde aber streng genommen in die FCL gehören, da es keine Abhängigkeit von der LCL hat.
Das Ganze bringt aber nicht viel, da die Lazarus unabhängigen Teile stabil sind.
D.h. sie müssen nicht im "Entwicklungsstrom" mitschwimmen und ich werde daran auch nichts mehr ändern. Du kannst also mit den Units die du hast, heute Serveranwendungen, Batch Processing etc. schreiben - es gibt keinen Grund zur Annahme, dass diese Anwendungen wegen opbitmap einmal nicht mehr funktionieren sollten.

Wenn man das OpBitmap Package meint, so gibt es Lizenzfragen bezüglich der Bildformat-Units. Diese sind ja nicht von mir geschrieben, sondern ein Hauptgrund für opbitmap war es ja, diese für Delphi geschriebenen Units mit einem minimalen Portierungsaufwand verwenden zu können.
Das verwenden dieser Units ist zwar legal, aber die meisten passen nicht in das GPL / LGPL Schema.
Ausserdem würde man damit eine Doppelspurigkeit in der LCL auftun, denn es gibt ja schon JPEG, PNG, BMP R/W in der LCL, nur decken die R/W von OpBitmap (mind. JPEG, BMP) mehr Subformate ab.

[pluto]

Ich finde OpBitmap eigentlich nicht schlecht. Und verwende es auch schon um sicher zu gehen das die Grafik Formate auch geladen und da gestellt werden können.

In diesen Thread hast du beweisen das opBitmap schneller ist als TBitmap. für bestimmte aufgaben.

In allen Mein Projekten wo ich TBitmap verwende könnte ich praktischerweise auch OpBitmap verwenden.
Weil von TBitmap brauche ich im Prinzip nicht viel. Rechecke Zeichnen und sowas halt.

Evlt. werde ich das mal ausprobieren. Wie das mit opBitmap weiter geht. Wie gesagt ich nutzte es im Moment nur um Grafik Dateien laden und speichern zu können und um Transparente bereiche da zu stellen also Halbtranzparent !

Was mich am meisten stört es im Moment ei OpbItmap das ich das Bild einmal in ein TBitmap umwandeln muss. Könnte man das nicht irgendwie anders lösen durch API Funktionen ?
Sonst finde ich opBitmap nicht schlecht. und hoffe du wirst es weiter hin pflegen !

[theo]

Was mich am meisten stört es im Moment ei OpbItmap das ich das Bild einmal in ein TBitmap umwandeln muss. Könnte man das nicht irgendwie anders lösen durch API Funktionen ?

Das könnte man schon, ist aber ziemlich kompliziert und müsste für jedes Widgetset separat gemacht werden (Win32, GTK, Qt, Carbon....).
Ausserdem ändert sich die LCL auf dieser Ebene auch immer wieder, sodass die Stabilität letztlich schlechter wäre.
Vielleicht mach ich das mal für Lazarus 1.0, aber für den Moment lasse ich lieber LazIntfImage die "Drecksarbeit" machen. Das ist für alle besser so

[pluto]

schade !

[t-z]

Hier habe ich mal einen Benchmark mit opbitmap64 genmacht. Den Test habe ich mit Lazarus 0.9.28.2 64 Bit unter Windows 7 Professional 64 Bit gemacht. Es wurde FPC 2.2.4 verwendet. Die Grundlast meines System sah folgendermaßen aus: 3,5 GB freier RAM (5 GB verfügbar), 5-10% Grundlast auf einem i5-760 (4*2,8 GHz). Dies ist mein Quellcode:

Code: Alles auswählen

unit Unit1; 
 
{$mode objfpc}{$H+}
 
interface
 
uses
  Classes, SysUtils, FileUtil, LResources, Forms, Controls, Graphics, Dialogs,
  StdCtrls, LCLType, IntfGraphics, fpImage, opbitmap, lclintf{GetTickCount};
 
type
  //TRGBTripleArray = array[0..32767] of TRGBTriple;
  //PRGBTripleArray = ^TRGBTripleArray;
 
  { TForm1 }
 
  TForm1 = class(TForm)
    Button1: TButton;
    Edit1: TEdit;
    Edit2: TEdit;
    Edit3: TEdit;
    Edit4: TEdit;
    Edit5: TEdit;
    procedure Button1Click(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end; 
 
var
  Form1: TForm1; 
 
implementation
 
{ TForm1 }
 
procedure TForm1.Button1Click(Sender: TObject);
const w = 2000;
const h = 2000;
const l = 10;
var
  SrcIntfImg: TLazIntfImage;
  T2: TBitmap;
  OP: TCanvasOPBitmap;
  px, py, i: integer;
  s, e: Cardinal;
  Row: PRGBTripleArray;
  Line:PAPixel32;
begin
  //OpBitmap
  OP := TCanvasOPBitmap.Create;
  OP.Width := w;
  OP.Height := h;
  s := GetTickCount;
  for i:=0 to l do
   for py := 0 to h - 1 do
    for px := 0 to w - 1 do Op.Canvas.Pixels[px, py] := clred;
 
  e := GetTickCount - s;
  Edit1.Text:=InttoStr(e);
  OP.free;
 
  //OpBitmap mit Scanline
  OP := TCanvasOPBitmap.Create;
  OP.Width := w;
  OP.Height := h;
  OP.PixelFormat:=pf32bit;
  s := GetTickCount;
  for i:=0 to l do
   for py := 0 to h - 1 do
   begin
    Line:=Op.ScanLine[pY];
    for px := 0 to w - 1 do
    begin
      Line^[px].Red:=255;
      Line^[px].Blue:=0;
      Line^[px].Green:=0;
     end;
   end;
  e := GetTickCount - s;
  Edit2.Text:=InttoStr(e);
 
  //LazIntfImg
  SrcIntfImg := TLazIntfImage.Create(0, 0);
  SrcIntfImg.DataDescription := GetDescriptionFromDevice(0);
  SrcIntfImg.SetSize(w, h);
 
  s := GetTickCount;
  for i:=0 to l do
   for py := 0 to h - 1 do
     for px := 0 to w - 1 do SrcIntfImg.Colors[px, py] := colRed;
 
  e := GetTickCount - s;
  Edit3.Text:=InttoStr(e);
  SrcIntfImg.Free;
 
  //LazIntfImg2
  SrcIntfImg := TLazIntfImage.Create(0, 0);
  SrcIntfImg.DataDescription := GetDescriptionFromDevice(0);
  SrcIntfImg.SetSize(w, h);
 
  s := GetTickCount;
  for i:=0 to l do
    for py := 0 to h - 1 do
      begin
         Row := SrcIntfImg.GetDataLineStart(py);
         for px := 0 to w - 1 do
           begin
             row^[px].rgbtBlue :=0;
             row^[px].rgbtGreen:=0;
             row^[px].rgbtRed  :=255;
           end;
      end;
  e := GetTickCount - s;
  Edit4.Text:=InttoStr(e);
  SrcIntfImg.Free;
 
  //TBitmap
  T2 := TBitmap.Create;
  T2.Height := w;
  T2.Width := h;
 
  s := GetTickCount;
  for i:=0 to l do
   for py := 0 to h - 1 do
     for px := 0 to w - 1 do T2.Canvas.Pixels[px, py] := clred;
 
  e := GetTickCount - s;
  Edit5.Text:=InttoStr(e);
 
  T2.Free;
end;
 
 
initialization
  {$I unit1.lrs}
 
end.

Leider ist das Ergebnis zumindest unter meinen Testbedingungen ein wenig anders:

OpBitmap: 1326ms
LazIntfImg: 1139ms
LazIntfImg2: 515ms
TBitmap: 14913ms

Edit: Nun auch mit OP-Scanline (Quelltext und Anhänge sind geändert):
OpBitmap: 1326ms
OPScanline: 452ms
LazIntfImg: 1139ms
LazIntfImg2: 531ms
TBitmap: 14726ms

[mschnell]

Bestehen Pläne, die OPbitmap.pas eines Tages in das Lazarus-Projekt zu integrieren? Bzw. was spricht nach deiner Auffassung dagegen?

Etwas ähnliches entwickelt sich mit dem "fpGUI" Widget Type. Momentan verwendet fpGUI direkt (ohne externen Widget Set wie gtk) X11. Einer der Entwickler möchte aber auch ein "nacktes" Memory-Array als Pixel "Framebuffer" implementieren. (Siehe engische Lazarus-Enrtwicklungs Mailing Liste.)

-Michael