Windows GDI und WinAPI

[schnullerbacke]

Also bei Delphi klappt das so wie beschrieben. Tatsächlich braucht theo das ja auch nicht in der Form, das irgendwann später das Array vergrößert wird. Das wird in einer Rutsche auf volle Größe gebracht, die Anzahl der Pixel ist ja berechenbar, er weiß es halt nur nicht bevor er das Image geladen hat und zu dem Zeitpunkt ist die Farbtiefe nicht unbedingt klar. Nach dem Laden sind die Ausmaße fix und der Speicherbedarf steht fest. Dann kann man mit SetLength den Speicher allozieren und eben dann auch mit move verschieben.

Bei SetLength(arr, PixAnz) wird das klaglos klappen. Bei GetMem hätte ich da so meine Bedenken. GetMem alloziert Bytes und dürfte dabei kein word-alignment beachten, außer vielleicht für die Startadresse, danach wird Marke packed byte-alignment verwendet. Bei dyn-array dürfte er word-alignment beachten. Dadurch kanns dann bei 8- bzw. 24-Bit Farbtiefe zu ziemlichen Problemen kommen wenn man später per Array-Index zugreifen will, das wird word-align versuchen und damit zu spät aufsetzen.

[Christian]

Das wird ja warscheinlich auch so laufen es ist aber eben nicht definiert wenn die fpc entwickler irgendwann aus irgendwelchen gründen mal beschliessen den speicher für jedes element einzeln zu allociern z.b. weil das einen vorteil mit multicore prozessoren bietet weil die speicherbereiche dann einzeln von kernen angespriochen werden können (nur son schuss ins blaue) dann sucht theo sich n wolf das wollt ich nur damit gesagt haben das etwas ausserhalb der spezifikationen funktioniert muss noch lang nicht heissen das mans machen muss ist etwas was man im kommerziellen arbeitsalltag schmerzlich lernen muss

[schnullerbacke]

Deswegen benutz ich ja auch GetMem so gut wie nie. Höchstens mal wenn die Lebenszeit auf eine Prozedur lokal beschränkt ist. Ansonsten sind mir TList oder ein dyn-Array lieber, da ist man wenigstens auf der sicheren Seite. Verkettete Pointerliste mit New(fPixels) ist dann ja auch noch OK, wobei man da natürlich die Pointer auch in einem dyn-Array (array of pointer) speichern könnte. Das ist dann mehr ne Frage des Tempos oder des einfacheren Zugriffs. Auf jeden Fall ist es dann später wurscht ob man das auf einer 32-, 64- oder 128-Bit CPU ausführt. Neukompilieren langt, dann paßt es wieder.

[theo]

Also langsam beginne ich mich echt zu fragen, ob das noch mein Bock ist oder FPC's.

Weil ich nun längere Zeit an der Lazarus Version rumhantiert habe, ohne gegen Kylix zu testen,
habe ich das nun mal gemacht, um zu sehen, ob ich mir irgenwo einen "echten" Bug reinprogrammiert habe.
Ich habe die ganzen Codes der letzten FPC-Version in ein neues Verzeichnis kopiert,
Ein Kylix Projekt erstellt, die Sache eingebunden: kompiliert einwandfrei.

Das einzige was ich im Kylix Test neu geschrieben habe ist:

Code: Alles auswählen

procedure TForm1.Button2Click(Sender: TObject);
var
  searchResult: TSearchRec;
  Op: TJPEGImage;
begin
  SetCurrentDir('/home/theo/Documents/pics/');
 
  if FindFirst('*.jpg', faAnyFile, searchResult) = 0 then
  begin
    repeat
      Op := TJPEGImage.Create;
      Op.LoadFromFile(searchResult.Name);
 
      Image1.Picture.Bitmap.PixelFormat := QGraphics.pf32bit;
      Image1.Picture.Bitmap.width := op.Width;
      Image1.Picture.Bitmap.Height := op.Height;
      op.PixelFormat := opBitmap.pf32bit;
 
      Move(op.ScanLine[0]^, Image1.Picture.Bitmap.Scanline[0]^, op.Width * 4 * op.Height);
      Image1.Refresh;
 
      Op.free;
      Application.ProcessMessages;
 
    until FindNext(searchResult) <> 0;
    FindClose(searchResult);
  end;
end;

Also eine kleine "Slideshow" um möglichst schnell viele Bilder zu testen.
In dem Verzeichnis stecken ca 60 JPEGS.
Die Kylix-Version zeigt ohne murren alle an.

Eigentlich hatte ich gehofft, Kylix würde den Bug auch zeigen mit anderen Informationen dazu.
Aber läuft einfach. Dabei habe ich auch noch alle Rangecheck, Overflow check etc eingeschalten.

Also was kann es denn noch sein bei FPC (2.0.4 [2006/08/20] for i386)?
Mir gehen die Ideen aus. Hilfeeeeeee!

[Christian]

Was sagt denn der aktuelle 2.1.1 dazu ?
Im zweifelsfall konsultier mal die fpc mailinglist

was passiert denn mot {$mode delphi} ?

[theo]

was passiert denn mot {$mode delphi} ?

Danke Christian!
Fetten dicken Kuss!

Auch wenn andersrum ein Schuh draus wurde.
Ich hatte (aus irgendwelchen Experimentalgründen)
{$mode delphi} im SourceCode und vergessen zu entfernen.
Wenn dat weg ist läuft's!!

Warum weiss ich allerdings nicht.
Kompillieren tut's in beiden Modi.
Aber mit der einen Methode die ich habe, zeichnet es jetzt die JPEG Liste durch.
Bei der anderen Zeichenmethode, wo ich Move() verwende, wird jetzt dafür aber kräftig gehustet.

Wenigstens habe ich jetzt einen Anhaltspunkt.

Merci.

[Christian]

ich hätte es eher andersrum vermutet aber das beweist nur das man mode delphi nicht unbedingt einsetzen sollte automatische erkennung ob pointer oder nicht ist halt doch nich so ganz trivial
und tu mirn gefallen lass uns das mit dem küssen im stammtisch klärn da kann ich dich wenigstens hinterher verprügeln ohne gleich wieder alle gegen mich zu haben lol

[theo]

ich hätte es eher andersrum vermutet aber das beweist nur das man mode delphi nicht unbedingt einsetzen sollte automatische erkennung ob pointer oder nicht ist halt doch nich so ganz trivial

Aber betrifft das nicht eher die Kompilaton?
Müsste FPC nicht motzen if objfpc mode, wenn ich das nicht richtig gemacht hätte?
Gibt's irgendwo eine Information, was dieses $mode delphi genau anrichtet?

und tu mirn gefallen lass uns das mit dem küssen im stammtisch klärn da kann ich dich wenigstens hinterher verprügeln ohne gleich wieder alle gegen mich zu haben lol

Das habe ich doch nur im Überschwang der Freude gesagt, und weil ich weiss, dass du zuweit weg wohnst um das versprechen wahr zu machen

[theo]

Übrigens, wie du schon gesagt hast: Move scheint bei FPC in diesem Falle auch zu sporadischen Problemen zu führen. Ich mach das mal alles weg.

[Christian]

Aber betrifft das nicht eher die Kompilaton?
Müsste FPC nicht motzen if objfpc mode, wenn ich das nicht richtig gemacht hätte?
Gibt's irgendwo eine Information, was dieses $mode delphi genau anrichtet?

ne kenn leider keine doku hab ich neulich auch nach gesucht wo ich das problem mt mode fpc und mode objfpc hatte

aber generell ist mode objfpc ein recht sicherer mode und mode delphi versucht die schweinerein die im delphi möglich sind nachzuahmen hauptsächlich wohl das man nicht zwischen variablen und pointern unterscheiden muss sondern das der compiler selbst erkennt wundert mich immer wieder das das im delphi so gut funktioniert jedenfalls hab ich noch von keinen gravierenden problemen gehört.
aber ich denke auch da muss das mal schief gehen ich denke nicht das der compiler für jeden fall erraten kann was nun gemeint ist.

[schnullerbacke]

Bezieht sich bei Delphi ja eigentlich auch nur auf Objekte die von TObject abstammen oder mit class deklariert sind. Da findet sich auch allemal ne VMT, von daher ist das dann schon leicht rauszukriegen. Bei normalen pointern hab ich das noch nie ohne ^ probiert, ich hab das halt mal so gelernt, da macht man's automatisch...

Würde einem direkt was fehlen wenn das "Dach" nicht da wär...

[theo]

Möchte mal jemand testen?
Habe mein Dev-Progi hier raufgeladen (GTK / Linux).
http://www.theo.ch/lazarus/jpgtest.tar.gz" onclick="window.open(this.href);return false;

Ist nur so "status quo" mässig, kein Programm zum brauchen.
Zuerst eine JPEG, BMP, GIF Datei öffnen mit "öffnen".

Danach kann man in dem gleichen Verzeichnis ein Slideshow machen mit allen darin befindlichen JPEG/GIF/BMP (Button "SlideShow", 1000 ms sleep).

GIFs werden transparent angezeigt, BMPs auch mit RLE Encoding geöffnet und progressive JPEGs sind unterstützt.

Würde mich interessieren, ob's bei euch jetzt auch sauber läuft!

[schnullerbacke]

Ha,

läuft sogar mit GIF's, nur animated GIF's werden noch als Einzelbilder angezeigt.

[theo]

Ha, da bin ich ja erleichtert
Animated GIF würde schon auch gehen, bloss habe ich den "Mechanismus" hier nicht eingebaut.
Dafür aber Transparenz, die mich einige Zeit gekostet hat.

Welche Farbtiefe hat dein Screen?
Läuft's bei dir auch sauber? Keine Run Errors etc?

Danke für's testen!

[theo]

Dann habe ich gleich noch eine Frage an die Experten:

Ich bekomme im Modus {$S+} (Stack checking) immer Probleme bei der Übergabe eines Arrays in einer Prozedur.

Ich habe schon einige Varianten durch:

procedure TColorQuantizer.GetColorTable(var AColorTable: TColorTableArray);
procedure TColorQuantizer.GetColorTable(var AColorTable: array of TColor);
procedure TColorQuantizer.GetColorTable(AColorTable: PColorTableArray);
procedure TColorQuantizer.GetColorTable(AColorTable: POpenColorTableArray);

wobei:
TOpenColorTableArray = array of TColor;
POpenColorTableArray = ^TOpenColorTableArray;
TColorTableArray = array[0..$FF] of TColor;
PColorTableArray = ^TColorTableArray;

Ohne Stack checking läuft's prima. Aber ich krieg's nicht hin mit {$S+}

Also einfache Frage:
Wie kann ich einer Methode ein Array (max 256) übergeben, ohne dass der Stack checker kläfft!