Zeichenroutine frisst zuviel Speicher

[ak1]

Hallo Leute,

ich habe eine sehr umfangreiche Zeichenroutine, welche aus den Daten einer Datenbank eine Zeichnung erstellt. Diese Zeichnung wird auf einem TImage über Canvas. realisiert. In dieser Zeichenroutine sind unter anderem eine Menge "Textout", "MoveTo", "LineTo" und CopyRect-Anweisungen drin. Diese Zeichenroutine, welche ich nicht erstellt habe, aber verändern muss, frisst auf schwachen Rechnern zuviel Speicher und bringt mir dann entsprechende Meldungen (Zuwenig Speicher für diese Operation). Wie könnte ich das umgehen?

[sakura]

Diese Routinen selbst verbrauchen keinen Speicher. Es gibt also zwei Ansatzpunkte:

1. Die Grafik, welche erstellt wird ist viel zu groß (32 Bit, 1600x1200, ...)
2. Beim Verabeiten der Daten wird irgendwo geschludert und Speicher vollgepumpt!

Ohne Code-Samples können wir wenig mehr sagen.

...:cat:...

[ak1]

Hallo,

die Grafik ist sehr groß, geht über mehrere Bildschirme.
Wie hoch jetzt die Bitanzahl ist, weiss ich leider nicht, wie kann ich das feststellen?
Wie könnte ich das Problem mit der evtl. zu grossen Grafik lösen?


Der Speicher wird, so wie ich das sehen kann korrekt geleert. Die Fehlermeldung erscheint auch inmitten der Zeichenrpoutine (auf schwachen Rechnern).

Der Code ist meiner Meinung nach zu umfangreich um den hier zu posten, das ist eine sehr verzweigte Routine.

Gruß AK

[Gandalfus]

1. Kein TImage sondern eine Paintbox benutzen.
2. Alle zeichen Operationen auf einem Hintergrundbild ausführen und dann das Hintergrundbild mit BitBln() aufs Formular kopiern.
3. Wenn das nicht hilft Grafik kacheln.

mfg

[ak1]

Danke für den Tip mit der Paintbox. Das klappt schonmal, werde es gleich auf einem schwächeren Rechner ausprobieren und auf Speicherverbrauch testet.

Gruß

[ak1]

Hallo Gandalfus,

die Sache mit der Paintbox hat alleine erst mal nichts gebracht, die Fehlermeldung über zu wenig Arbeitsspeicher kommt auf dem alten Rechner immer noch.

Was meinst du mit:

Zitat:

2. Alle zeichen Operationen auf einem Hintergrundbild ausführen und dann das Hintergrundbild mit BitBln() aufs Formular
kopiern.
3. Wenn das nicht hilft Grafik kacheln.

Hast du ein Beispiel für ein Hintergrundbild und BitBln() ?
Was verstehst du unter kacheln?
Zeichnung aufteilen und am Schluss zusammensetzen?

Gruß AK

[Gandalfus]

Wie gross ist das Bild?

[Stanlay Hanks]

Zitat:

Zitat von ak1

die Grafik ist sehr groß, geht über mehrere Bildschirme.

@Gandalfus Wahrscheinlich ziemlich groß :wink:

@ak1 Ich weiß nicht, ob ich da jetzt einen Denkfehler hab, aber wie wärs, wenn du das Bild aus lauter kleineren (sagen wir 10 Teilen) zusammensetzt?

Man liest sich, Stanlay :hi:

[ak1]

Hallo Gandalfus,

das Bild ist ca. 1,5 Bildschirme hoch und 4,14 Meter breit (scrollbar), da es sich um geographische Daten handelt, die in einem korrekten Maaßstab angezeigt werden, kann ich die Breite ziemlich genau angeben.

Auf einem Athlon 2000 mit 512mb Ram reicht der Speicher für dieses Bild auch nicht....trotz Paintbox


Gruß

[dizzy]

Zitat:

Zitat von ak1

Hallo Gandalfus,

das Bild ist ca. 1,5 Bildschirme hoch und 4,14 Meter breit (scrollbar), da es sich um geographische Daten handelt, die in einem korrekten Maaßstab angezeigt werden, kann ich die Breite ziemlich genau angeben.

Auf einem Athlon 2000 mit 512mb Ram reicht der Speicher für dieses Bild auch nicht....trotz Paintbox


Gruß

Mal angenommen, 1,5 Bildschirme mit einer Auflösung von 1280x1024: Das Bild ist schonmal 1920 Pixel hoch.

Jetzt zur Breite... nun, nehmen wir an es handelt sich um einen 19"-Schirm. Bei mir passen 1280 Pixel auf 34cm - das macht dann rund 37,65 Pixel pro cm.

414 cm sollen es sein, also 414*37,65 = rund 15587 Pixel in der Breite.

okay, das Bild ist also 15.587x1.920 Pixel. Macht 29.927.040 einzelne Pixel. In der Regel arbeitet man mit 24Bit-Bitmaps, also den Spaß nochmal mit 24 Multiplizieren.
Das ergibt dann: 718.248.960 Bit = 89.781.120 Byte = 87.677 MB = 85,62 GB

Das Bild bräuchte schon ganz für sich alleine genommen satte 85,62 GigaByte Speicher... Je nach Größe der Auslagerungsdatei...... :stupid:


Und kleinen Auflösungen, und niedrigere Farbtiefe bringen zwar etwas, aber du wirst dich bei einer solchen Größe immer hart an der Grenze bewegen. Die einzige Möglichkeit das in den Griff zu bekommen ist, immer zu errechnen, welcher Bildausschnitt gerade sichtbar sein soll, und nur diesen dann frisch zu Zeichnen. Soll heissen, dein Bild existiert nie in Gänze, nur als Ausgangsinformation. Nur der Bereich der relevant ist wird gezeigt. Nicht einfach, aber machbar und wohl einer der wenigen praktikablen Wege hier...


btw: Wenn du mal eben etwas an der Breite-Einstellung deines Monitors drehst, sind deine 4,14 Meter bei gleichbleibender Pixelzahl auf einmal mehr oder weniger. Gleiches Spiel bei anderen Monitorformaten! Um eine solche Angabe genau treffen zu können, muss man zuvor mit Hilfe des Users den Bildschirm physikalisch ausmessen und kalibrieren! Sonst weisst du nie mit Bestimmtheit, wie viele Pixel in einen cm passen.


gruss,
dizzy

[ak1]

@Dizziy, das ist eine beeindruckende Rechnung, komischerweise lassen sich die Bilder, welche nur halb so gross sin, anzeigen. Und 40GB hat die Auslagerungsdatei bestimmt nicht ;-) ....ich werde das Bild zerhacken, weil es anders wohl nicht geht.


Gruß

[dizzy]

Ach du K***, hab mich da voll vertan an einer Stelle... Ich hab' die Kilobytes vergessen :\

Also heisst es:

718.248.960 Bit = 89.781.120 Byte = 87.677 kB = 85,62 MB

Mal für 32Bit-Bitmaps:
957.665.280 Bit = 119.708.160 Byte = 116.902,5 kB = 114,2 MB


Dann sieht das nicht mehr nach so viel aus :mrgreen: :roll: :oops:
Aber trotz alle dem nicht gerade klein, und je nach dem was alles im Hintergrund mitläuft, und wieviel RAM dann noch über ist, können auch 100MB einem in die Suppe spucken.

Aber es kann grundsätzlich nicht schaden, solche Riesenausgaben wie beschrieben zu unterteilen.


gruss,
dizzy

[Gandalfus]

selbst wenn das unter XP läuft unter 98 geht das mit so grossen Bildern niemals. Das Bild muss zerteilt werden wie das jetzt in deinem Fall geht kann man ohne code nicht sagen.

Delphi-Quellcode:

ich würde das in etwa so machen:

type 
  TBildteil = object;
  puplic
    width,height: integer;
    left,top: integer;
    Bild: TBitmap;
    constructor create;
    destructor destroy; override;
  end;

[..]

constructor TBildteil.create;
begin
  inherited;
  Bild := TBItmap.create;;
end;

destructor TBildteil.destroy;
begin
  Bild.free;
  inherited;
end;


var
  Bildteil : array [0..2,0..2] of TBildteil;

[..]
for x:=0 to 2 do
begin
  for y:=0 to 2 do
  begin
    Bildteil[x,y] := TBildteil.create;
    Bildteil.left := x;
    Bildteil.top := y;
  end;
end;

Bildteil[0,0].bild.asign(BIldteil1) 
....


zeichnen:
for x:=0 to 2 do
begin
  for y:=0 to 2 do
  begin
    //hab im Moment keien Zeit mehr 
  end;
end;

mfg

[ak1]

@Dizzi und Co.

ich hab aus einem andern forum einen interessanten Link zum Thema bekommen:
http://www.efg2.com/Lab/Graphics/VeryLargeBitmap.htm

Es liegt wohl weder an Delphi, sondern vielmehr an Windows, welches Probleme mit grossen bildern hat. Da kann der speicher nur bedingt etwas ausrichten, da ja in meinem Fall 512 MB hätten ausreichen müssen...aber lest selbst.

[dizzy]

Hat ja keiner gesagt, dass es an Delphi läge ;)
Die Seite kannte ich sogar schon - diesen Artikel hab ich mir zu meiner Schande aber noch nie angesehen - sehr hilfreiches Zeug da!

Aber das zeigt ja noch deutlicher, dass man auf jeden Fall splitten sollte, wenn das Programm auch noch auf älteren Rechnern lauffähig sein soll. Wahrscheinlich liegst du mit deiner Bildgröße mit im oberen Drittel (Wertemäßig, nicht der Position nach gesehen) der dort gezeigten Tabelle.

Danke aber für den Hinweis. Wer weiss, ob man nicht ganz fix selber vor dem gleichen Problemchen steht... :)


gruss,
dizzy