Speichermangel- Problem mit grossen Bitmaps...



  • Hallo ihr Experten...

    Ich habe folgendes Problem:
    1. Eine Application , welche Bilddateien lädt, anzeigt und bearbeitet...
    2. Geladen werden TIF,PNG,BMP...
    3. zum Bearbeiten (auch Geometrie- Änderungen) wird eine zweite (3.) Kopie nötig.
    4. I.A. klappt eigentlich (fast) alles. AUSSER:

    Bei Dateien mit mehr als 65 MPIXEL Kann die Datei NICHT geladen werden?
    Bei BMP- Dateien gehen z.T. auch noch 100 MPixel Dateien (und ev. leicht höher).

    Zum Bearbeiten kann aber keine zweite Kopie angelegt werden - das ist aber nötig!.

    Das Problem: Im Heap sind laut Abfrage auch noch >1 GBYTE frei! Aber ein zweites BITMAP kann nicht in der Grösse erzeugt werden.

    HEAPCOMPACT(...) schafft manchmal Abhilfe, aber nicht immer.

    WAS kann hier Abhilfe schaffen?

    Das Tool sollte auch 300MPIXEL- Dateien verarbeiten können.
    Das ist z.B. für gescannte Landkarten nötig!

    WICHTIG ist, dass wenigstens die Datei geöffnet werden kann. Zur Bearbeiten kann ich eine eigen BITMAP- Klasse nehmen, welche die Daten auch verteilt im RAM halten/ bearbeiten kann...

    Gruss
    Frank

    PS: Bei Compilieren als Standalone- EXE gehen auch z.T. grössere BMP- Dateien (bis 150 MPIXEL. Aber auch nur als BMPs.
    Wie kann das dann gehen? Welcher Zusammenhang besteht da?



  • memory fragmentation ?



  • Dein Problem besteht in der Fragmentierung nicht des Speichers, sondern des Adreßraums. Daraus folgt auch schon die erste mögliche Abhilfe: verwende einen 64-Bit-Prozeß.

    DerAltenburger schrieb:

    WAS kann hier Abhilfe schaffen?
    [...]
    WICHTIG ist, dass wenigstens die Datei geöffnet werden kann.

    Für solche Fälle würde ich die Verwendung von memory-mapped files in Erwägung ziehen. Damit kannst du den gerade relevanten Ausschnitt der Datei bequem in den Speicher einblenden. Allerdings ist das nur sinnvoll bei Bitmaps, weil die trivial einzulesen sind und weil ein linearer Zusammenhang zwischen Bildposition und Speicherposition besteht. Weil du die Extraktion eines Bitmaps aus einer JPEG- oder PNG-Datei sicher nicht von Hand vornehmen willst, wirst du bei diesen auf solche Tricks verzichten müssen.



  • audacia schrieb:

    Dein Problem besteht in der Fragmentierung nicht des Speichers,

    doch, per Definition: Memory fragmentation = 1 - größter zusammenhängender freier Speicherblock / Gesatmgröße.



  • klassenmethode schrieb:

    audacia schrieb:

    Dein Problem besteht in der Fragmentierung nicht des Speichers,

    doch, per Definition: Memory fragmentation = 1 - größter zusammenhängender freier Speicherblock / Gesatmgröße.

    Das dachte ich mir auch. Der grösste freie Block ist z.T. nur 300MByte .. 380 MByte, obwohl gesamt fer >1 GByte ist...

    Nur was dagegen tun?

    HeapCompact bringt nicht allzu viel...
    (Der grösste Block reicht auch danach nicht unbedingt...

    Gruss
    Frank



  • audacia schrieb:

    Dein Problem besteht in der Fragmentierung nicht des Speichers, sondern des Adreßraums. Daraus folgt auch schon die erste mögliche Abhilfe: verwende einen 64-Bit-Prozeß.

    Das geht leider nicht, habe nur ein 32Bit System und Compiler!

    DerAltenburger schrieb:

    WAS kann hier Abhilfe schaffen?
    [...]
    WICHTIG ist, dass wenigstens die Datei geöffnet werden kann.

    Für solche Fälle würde ich die Verwendung von memory-mapped files in Erwägung ziehen. Damit kannst du den gerade relevanten Ausschnitt der Datei bequem in den Speicher einblenden. Allerdings ist das nur sinnvoll bei Bitmaps, weil die trivial einzulesen sind und weil ein linearer Zusammenhang zwischen Bildposition und Speicherposition besteht. Weil du die Extraktion eines Bitmaps aus einer JPEG- oder PNG-Datei sicher nicht von Hand vornehmen willst, wirst du bei diesen auf solche Tricks verzichten müssen.

    So was wie MAPPED FILE habe ich befürchtet...

    Aber wie bekomme ich die BITMAP aus der Datei direkt in ein Mapped File?
    Oder muss das NACH dem Laden in ein TBitmap dann selber darein "kopiert" werden.

    UND: Als erstes brauche ich ja das Bild in einem TBitmap um das ganze Zoom- bar anzeigen zu können.

    *******************************************************
    Könnte die RAM- Fragmentierung auch verringert werden, wenn das Programm nur wenig Oberflächen- Elemente und zugehörige Methoden/ Ereignisse hat?

    Das Tool hat sehr viele Funktionen mit Dutzenden Einstellern/ Anzeigen und entsprechenden Methoden... Die sind auf 8 Registerkarten verteilt...

    Im Hintergrund werden auch Objekte erzeugt/ freigegeben um "PolyLinien darzustellen. Für gebogene PolyLinien werden dabei z.T. erhebliche Mengen an spez. RealPoint- Objekten erzeugt - pro Bogen- Segment auch mal Hunderte!

    ACHTUNG:
    Das Freigeben meiner Objekt ist NICHT die Ursache, das klappt bestens - es entstehen definitiv KEINE Datenleichen im RAM! Aber ev. ne Fragmentierung...

    Für den "Härtefall könnte ich alles bis auf ein Register mit den Funktionen reduzieren. Die Frage ist: kann das was bringen?

    Gruss
    Frank

    Wer sich das Ansehen möchte: auf meiner HP als "DigitalPhotoWarper" als Demo- Installer downloadbar. Das Tool soll auf grosse Landkarten optimiert werden. Dazu genügt dann der Modul "Field- Warp"



  • DerAltenburger schrieb:

    Aber wie bekomme ich die BITMAP aus der Datei direkt in ein Mapped File?
    Oder muss das NACH dem Laden in ein TBitmap dann selber darein "kopiert" werden.

    Nein, du kannst zum Laden der Datei kein TBitmap oder sonstige Wrapperklassen verwenden. Stattdessen öffnest du die Bitmap-Datei mit CreateFileMapping(), blendest einen Teil der Datei mit MapViewOfFile() in den Speicher ein und liest dann den Bitmap-Header ein, um direkt an die gewünschte Stelle im Bild springen zu können (dafür benutzt du jeweils MapViewOfFile() und UnmapViewOfFile()). Details zum Bitmap-Dateiformat findest du z.B. im Petzold. Aus dem eingeblendeten Speicherbereich kopierst du den gewünschten Bildausschnitt zeilenweise in ein TBitmap , das du dann auf dem Bildschirm anzeigen kannst.

    DerAltenburger schrieb:

    Könnte die RAM- Fragmentierung auch verringert werden, wenn das Programm nur wenig Oberflächen- Elemente und zugehörige Methoden/ Ereignisse hat?

    Möglich, daß es ein ganz klein bißchen besser wird, aber du solltest dich nicht drauf verlassen. Das kann auf einem anderen Rechner mit einer anderen OS-Version und anderer Speicherbestückung wieder anders aussehen.

    DerAltenburger schrieb:

    ACHTUNG:
    Das Freigeben meiner Objekt ist NICHT die Ursache, das klappt bestens - es entstehen definitiv KEINE Datenleichen im RAM!

    Das sagen sie alle 🙂

    DerAltenburger schrieb:

    So was wie MAPPED FILE habe ich befürchtet...

    Wie gesagt, wenns dir zu kompliziert wird, solltest du eine 64-Bit-Anwendung erstellen, dann bist du solche Probleme los.



  • audacia schrieb:

    DerAltenburger schrieb:

    Aber wie bekomme ich die BITMAP aus der Datei direkt in ein Mapped File?
    Oder muss das NACH dem Laden in ein TBitmap dann selber darein "kopiert" werden.

    Nein, du kannst zum Laden der Datei kein TBitmap oder sonstige Wrapperklassen verwenden. Stattdessen öffnest du die Bitmap-Datei mit CreateFileMapping(), blendest einen Teil der Datei mit MapViewOfFile() in den Speicher ein und liest dann den Bitmap-Header ein, um direkt an die gewünschte Stelle im Bild springen zu können (dafür benutzt du jeweils MapViewOfFile() und UnmapViewOfFile()).

    Hast Du bauch einen Tip, wie ich genau an die richtige Stelle kommen? Hab noch nie wirklich mit Bitmap- Header- Infos gearbeitet. Bisher ging das alles immer direkt mit TBitmap von Borland...

    audacia schrieb:

    ...
    Aus dem eingeblendeten Speicherbereich kopierst du den gewünschten Bildausschnitt zeilenweise in ein TBitmap , das du dann auf dem Bildschirm anzeigen kannst.

    Das Problem: Ich muss z.T. auch das gesamte Bild (klein- gezoomt) im Ganzen anzeigen können. Dann muss ja der eingeblendete Bereich über alles gehen...

    audacia schrieb:

    DerAltenburger schrieb:

    ACHTUNG:
    Das Freigeben meiner Objekt ist NICHT die Ursache, das klappt bestens - es entstehen definitiv KEINE Datenleichen im RAM!

    Das sagen sie alle 🙂
    Hier stimmt das aber tatsächlich! Ich habe für alle meine CAD- artigen Objekte einen Total- Counter eingebaut. Und der steht am Ende bei allen wieder auf 0. Egal wie viele Objekte davon erzeugt wurden - das sind z.T. Hunderte oder mehr (z.B. Stützpunkte für PolyLinien)

    DerAltenburger schrieb:

    Könnte die RAM- Fragmentierung auch verringert werden, wenn das Programm nur wenig Oberflächen- Elemente und zugehörige Methoden/ Ereignisse hat?

    Möglich, daß es ein ganz klein bißchen besser wird, aber du solltest dich nicht drauf verlassen. Das kann auf einem anderen Rechner mit einer anderen OS-Version und anderer Speicherbestückung wieder anders aussehen.

    Das klingt plausibel. Schade.

    Danke erstmal allen für die Tips. Dann wird ich mich mal an das File- Mapping ranmachen "müssen".

    Gruss
    Frank



  • DerAltenburger schrieb:

    Hast Du bauch einen Tip, wie ich genau an die richtige Stelle kommen? Hab noch nie wirklich mit Bitmap- Header- Infos gearbeitet.

    Hab ich doch schon gesagt. Alle Informationen zu Bitmap-Headern findest du im MSDN, und wenn du eine ausführliche Einführung in das Dateiformat möchtest, schau im Petzold nach.

    (Wenn du bei der Suchmaschine deiner Wahl nach "petzold dib file format" suchst, findest du das entsprechende Kapitel in einer vermutlich nicht autorisierten Veröffentlichung auf einer privaten Website; weil das Buch leider nur noch antiquarisch erhältlich ist, halten sich meine Bedenken dabei in Grenzen.)

    DerAltenburger schrieb:

    Das Problem: Ich muss z.T. auch das gesamte Bild (klein- gezoomt) im Ganzen anzeigen können. Dann muss ja der eingeblendete Bereich über alles gehen...

    Nein, aber dann solltest du zuerst einen Durchgang machen und eine Reihe von Mipmaps anlegen. Die "kleiner gezoomten" Bilder nehmen ja nicht viel Platz weg, also erstellst du die einmal vorab und speicherst sie. Für so einen Durchgang ist es nicht erforderlich, den gesamten Speicherbereich auf einmal einzublenden.

    DerAltenburger schrieb:

    Danke erstmal allen für die Tips. Dann wird ich mich mal an das File- Mapping ranmachen "müssen".

    Nein, du kannst auch stattdessen einen 64-Bit-Prozeß machen 🙂 Aber da du diesen Hinweis beständig übergehst, scheint das gar nicht in Frage zu kommen.



  • Was sind das eigentlich für Dateien, die dein Programm da öffnet? Kommen die direkt aus dem Scanner? Wer erstellt diese Dateien; machen die Benutzer deines Programmes das selbständig, oder bist du auch durch ein Programm von dir an der Erstellung beteiligt?

    Ich frage, weil die obige Diskussion zwar dazu helfen dürfte, dein konkretes Problem (Adreßraumfragmentation) zu beheben, aber wenn die Bedienung deines Programms so funktionieren soll, wie ich mir das gerade vorstelle (nämlich so ähnlich wie in Google Maps bzgl. Zoomen und Verschieben der Karte), und wenn große Karten die Regel sind, dann würde ich etwas anders an die Sache herangehen. Insbesondere würde sich eine Vorverarbeitung der Kartendateien anbieten, die den Umgang mit den Daten bequemer und effizienter macht.



  • audacia schrieb:

    DerAltenburger schrieb:

    Danke erstmal allen für die Tips. Dann wird ich mich mal an das File- Mapping ranmachen "müssen".

    Nein, du kannst auch stattdessen einen 64-Bit-Prozeß machen 🙂 Aber da du diesen Hinweis beständig übergehst, scheint das gar nicht in Frage zu kommen.

    Ich sagte ja schonmal, ich hab nur 32Bit System/ Compiler.
    Ist klar, mit 64Bit und genug RAM wäre das Problem aus der Welt.

    audacia schrieb:

    DerAltenburger schrieb:

    Das Problem: Ich muss z.T. auch das gesamte Bild (klein- gezoomt) im Ganzen anzeigen können. Dann muss ja der eingeblendete Bereich über alles gehen...

    Nein, aber dann solltest du zuerst einen Durchgang machen und eine Reihe von Mipmaps anlegen. Die "kleiner gezoomten" Bilder nehmen ja nicht viel Platz weg, also erstellst du die einmal vorab und speicherst sie. Für so einen Durchgang ist es nicht erforderlich, den gesamten Speicherbereich auf einmal einzublenden.

    Na ja, für die erste Halbierung muss doch das komplette Bild "kleingerechnet" werden...
    Danach wird es dann immer besser...
    Ist nicht die Summe der Bildflächen aller MIP- Maps annähernd die Grösse des Originals? Klar, die liegen nicht zusammenhängend im RAM, nur jedes MipMap für sich.

    Gruss
    Frank



  • audacia schrieb:

    Was sind das eigentlich für Dateien, die dein Programm da öffnet? Kommen die direkt aus dem Scanner? Wer erstellt diese Dateien; machen die Benutzer deines Programmes das selbständig, oder bist du auch durch ein Programm von dir an der Erstellung beteiligt?

    Das sind gescannte Karten von einer Behörde!
    Die kommen direkt aus dem Scanner - z.T. als TIF. Ich kann aber auch BMP als Vorgabe nennen, das ginge schon.
    Mit dem Scannen habe ich nichts zu tun. Ich soll nur Kanten- Krümmungen/ Verzug rausrechnen - deshalb hatte ich ja meinen "Field- Warp" Modul vorgesehen.
    Das Warpen ist auch nur bedingt das Problem - das dauert halt etwas!

    audacia schrieb:

    Ich frage, weil die obige Diskussion zwar dazu helfen dürfte, dein konkretes Problem (Adreßraumfragmentation) zu beheben, aber wenn die Bedienung deines Programms so funktionieren soll, wie ich mir das gerade vorstelle (nämlich so ähnlich wie in Google Maps bzgl. Zoomen und Verschieben der Karte), und wenn große Karten die Regel sind, dann würde ich etwas anders an die Sache herangehen. Insbesondere würde sich eine Vorverarbeitung der Kartendateien anbieten, die den Umgang mit den Daten bequemer und effizienter macht.

    Die Karte soll aus einer Liste auswählbar sein - dazu will ich diese als Gesamtbild VOR der Verarbeitung komplett anzeigen, zur Kontrolle, ob es die richtige ist.
    In der Karte (gesamt) muss ein Rahmen (4- Eck) eingestellt werden (als editierbare Kontur - dazu habe ich CAD- artige Strukturen/ Objekte).
    Alle 4 Kanten sollen frei zu Bögen gemacht werden können.

    Am Ende wird der Bild- Inhalt innerhalb des "verbogenen" Vierecks in ein gerades Zielviereck gewarpt. Damit sind ev. Krümmungen der Kanten weg!
    Ev. mus die Krümmung auch noch komplexer weggerechnet werden. Aber das ist mit einem Mesh- Warp Mechanismus auch kein Problem. (Gitternetz mit geschwungenen Splines)

    Für BMP- Dateien bis 130 MPixel hab ich das jetzt hinbekommen (Alles rausgehauen, was nicht unbedingt nötig war, HeapCompact bei Bedarf starten und Laden wiederholt...
    Das klappt z.T. auch schon mit TIF- Dateien.
    (Laden schlägt fehl=> Mit HeapCompact Speicher optimieren und nochmal Laden - dann klappt das (meistens).

    Bei 260MPixel Scans geht es auch mit BMP- Dateien. Bei TIF hängts es noch daran:
    Nach dem Laden der TIF- Datei - das mach ich mit GDI+ - wandle ich das in ein HBITMAP (und das kommt dann in ein Borlnd TBITMAP- Objekt. aber inn dem Moment muss scheinbar das Bild zweimal gleichzeitig AM STÜCK in den RAM - und da ist dann Essig mit 32bit Programmen...

    WICHTIG:
    Das ganze klappt nur als Standalone!
    (OHNE dynamische RTL, NICHT mit Packages!)
    Das hatte mich ja am meisten gewundert.
    Habe Win Vista, 32bit und 4GB Ram. Im Programm sind 1.7 ... 2.1 GByte gesamt frei.

    Gruss
    Frank



  • DerAltenburger schrieb:

    Ich sagte ja schonmal, ich hab nur 32Bit System/ Compiler.

    Ah, jetzt seh' ich's auch, du hast in einen Zitatblock reingeschrieben. Bitte mach das nicht, sowas überliest man leicht.

    DerAltenburger schrieb:

    Ist klar, mit 64Bit und genug RAM wäre das Problem aus der Welt.

    Du hast genug RAM. Es geht wirklich um den Adreßraum. Selbst bei gleicher Menge RAM hat ein 64-Bit-Prozeß genug Adreßraum zur Verfügung, um große zusammenhängende Speicherbereiche zu allozieren.

    DerAltenburger schrieb:

    Ist nicht die Summe der Bildflächen aller MIP- Maps annähernd die Grösse des Originals?

    Ungefähr, ja. Aber du mußt sie ja nicht alle speichern, die paar kleinsten dürften reichen.

    DerAltenburger schrieb:

    Die Karte soll aus einer Liste auswählbar sein - dazu will ich diese als Gesamtbild VOR der Verarbeitung komplett anzeigen, zur Kontrolle, ob es die richtige ist.

    Gut, dann brauchst du ja gar nicht das ganze Mipmap.

    So wie du deine Anforderungen beschreibst, würde ich wohl bei den memory-mapped files bleiben. Für die Handhabung von BMP-Dateien hast du ja nun genug Material. Wenn ich es recht verstehe, verzerrst du das Bild nur und schreibst es dann wieder in eine Datei; dann brauchst du ja gar kein TBitmap . Du mußt nur deinen Verzerrungsalgorithmus etwas anpassen.

    Deine Verzerrungstransformation dürfte ja invertierbar sein, oder? Dann mach es doch folgendermaßen:

    - das Ursprungsbild lädst du als memory-mapped file und blendest erstmal nur den Header ein
    - du kannst ja berechnen, wie groß das Zielbild sein muß; also legst du die Zieldatei mit CreateFile() an und benutzt dann SetEndOfFile(), um die Dateigröße zu setzen
    - jetzt unterteilst du das Zielbild (N×MpxN \times M \; \mathrm{px}) in Zeilenblöcke (kk Blöcke mit je N×MkpxN \times \frac{M}{k} \mathrm{px}), so daß jeder Zeilenblock zMBz \; \mathrm{MB} groß ist
    - für einen Zeilenblock im Zielbild kannst du ausrechnen, auf welche Zeilen des Ursprungsbildes du zugreifen können mußt; also rufst du für beide Bilder MapViewOfFile() mit dem jeweiligen Speicherbereich auf
    - für jeden Pixel im Zeilenblock bestimmst du dann mittels deiner inversen Transformation die entsprechenden Pixel im Originalbild
    - dann schließt du die beiden Mappings mit UnmapViewOfFile() und gehst zum nächsten Zeilenblock

    Mit der Methode brauchst du nur etwa 3×zMB3 \times z \; \mathrm{MB} Speicher. Wie du zz bemißt, ist deine Wahl; machst du es größer, hast du weniger Festplattenzugriffe, machst du es kleiner, paßt der Speicherbereich vielleicht in den CPU-Cache. Müßtest du mal mit rumexperimentieren.



  • audacia schrieb:

    DerAltenburger schrieb:

    Ich sagte ja schonmal, ich hab nur 32Bit System/ Compiler.

    Ah, jetzt seh' ich's auch, du hast in einen Zitatblock reingeschrieben. Bitte mach das nicht, sowas überliest man leicht.

    Sorry, versuch ich sonst auch nicht zu machen...

    audacia schrieb:

    DerAltenburger schrieb:

    Ist nicht die Summe der Bildflächen aller MIP- Maps annähernd die Grösse des Originals?

    Ungefähr, ja. Aber du mußt sie ja nicht alle speichern, die paar kleinsten dürften reichen.

    Wenn ich das Komplettbild eingezoomt darstellen will, muss ich doch vom ganzen Bitmap ausgehend Skalieren/ Interpolieren.
    Oder: Das erste verkleinerte Mipmap (1/2 Grösse) muss doch vom ganzen Bitmap ausgehend Skalieren/ Interpolieren.Die Anzeige kann am Ende ja dann ein geeignetes Mipmap verwenden...

    Ok: die erste Stufe der Verklerinerung/ Anzeige kann ja direkt aus dem MapViewOfFile heraus berechnen...
    Dann brauche ich kein TBitmap...

    audacia schrieb:

    Deine Verzerrungstransformation dürfte ja invertierbar sein, oder? Dann mach es doch folgendermaßen:

    - das Ursprungsbild lädst du als memory-mapped file und blendest erstmal nur den Header ein
    - du kannst ja berechnen, wie groß das Zielbild sein muß; also legst du die Zieldatei mit CreateFile() an und benutzt dann SetEndOfFile(), um die Dateigröße zu setzen
    - jetzt unterteilst du das Zielbild (N×MpxN \times M \; \mathrm{px}) in Zeilenblöcke (kk Blöcke mit je N×MkpxN \times \frac{M}{k} \mathrm{px}), so daß jeder Zeilenblock zMBz \; \mathrm{MB} groß ist
    - für einen Zeilenblock im Zielbild kannst du ausrechnen, auf welche Zeilen des Ursprungsbildes du zugreifen können mußt; also rufst du für beide Bilder MapViewOfFile() mit dem jeweiligen Speicherbereich auf
    - für jeden Pixel im Zeilenblock bestimmst du dann mittels deiner inversen Transformation die entsprechenden Pixel im Originalbild
    - dann schließt du die beiden Mappings mit UnmapViewOfFile() und gehst zum nächsten Zeilenblock

    Mit der Methode brauchst du nur etwa 3×zMB3 \times z \; \mathrm{MB} Speicher. Wie du zz bemißt, ist deine Wahl; machst du es größer, hast du weniger Festplattenzugriffe, machst du es kleiner, paßt der Speicherbereich vielleicht in den CPU-Cache. Müßtest du mal mit rumexperimentieren.

    Meine Transformation ist schon invertiert - die lässte sich immer invertieren.
    (Man muss ja zu Zielpixel berechnen aus welchen Quellpixel(n) die Daten kommen...

    Das wird das wohl auf FileMapping hinauslaufen!

    Ich wollte nur die Daten nach dem Einlesen gern in einem TBitmap haben:
    - Da kann ich ohne Probleme auf Scanlines/ Pixel zugreifen
    - Da muss ich mich NICHT mit Bitmap- Header & Co rumschlagen
    - Da brauche ich auch keine "internen" Kenntnisse zu BM- Dateien...
    Ist aber ne Form der Bequemlichkeit. Wenn es nicht anders geht, muss eben was Anderes her - und wenn das FileMapping ist 🙂 !

    Bis zu ca 300MPixel habe ich auch ein eigenes TMyBitmap:
    - liest Daten Zeilenweise ein! (RGB- Tripel) je einer Zeile
    - Alle diese "ScanLines" werden in Array gespeichert für schnellen Zugriff
    - Es braucht KEINEN RAM- Block für das ganze Bild. Nur jew. für eine Zeile.
    Problem ist nur, die Daten aus der Datei in meine Klasse zu bekommen. Das geht am einfachsten aus einem Borland TBitmap.
    Aber mit FileMapping sollte das auch gehen - Du hast ja viele Tips gegeben.

    - Meine Zoom- Anzeige ist so aufgebaut, dass die Daten in ein komplettes TBitmap kommen und daraus dann die Anzeige (gepuffert) skaliert wird. Das müsste ich dann ev. auch auf FileMapping umstellen. Das wollte ich eigentlich vermeiden, aber wenns nötig ist sollte das schon gehen.

    Gruss & Dank
    Frank


Log in to reply