Autor Beitrag
Tastaro
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 414
Erhaltene Danke: 23



BeitragVerfasst: Do 13.11.14 16:43 
Hallo,

wenn ich eine TPaintBox verwende, dann habe ich ja pro Pixel 4 Byte Farbe.
Ich brache aber gar nicht so viel und würde gerne Speicher sparen, da meine Bilder recht groß werden. (Mit den 4 Byte Farbe habe ich gerade 650 MB RAM belegt oO).
Gibt es eine PaintBox, oder andere Komponente, die nur 255 Farben verwendet und der man diese Farben (Stichwort: Palette) zuweisen kann?
FinnO
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 1331
Erhaltene Danke: 123

Mac OSX, Arch
TypeScript (Webstorm), Kotlin, Clojure (IDEA), Golang (VSCode)
BeitragVerfasst: Do 13.11.14 18:45 
Moin,

dein Problem ist eher konzeptueller Natur. Du trennst sehr wahrscheinlich deine Daten nicht gut von der Oberfläche. Denn ich kann mir kaum Vorstellen, dass du rund 160 Megapixel auf deinem Display anzeigen kannst.

Du kannst also für deine Daten zum Beispiel ein array of byte verwenden, und nur die tatsächlichen Bilder dann (z.B. in Graustufen) in der Paintbox darstellen. Das sollte den benötigten Arbeitsspeicher etwas verringern. Falls das ganze natürlich beliebig weiter so ausartet, musst du anfangen, nur die Daten die du tatsächlich benötigst in den RAM zu laden und den Rest auf der Platte liegen zu lassen.

Zusätzlich kannst du das PixelFormat der Bitmap aber noch auf pf8bit setzen.

Gruß
Tastaro Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 414
Erhaltene Danke: 23



BeitragVerfasst: Fr 14.11.14 08:31 
Hallo,

natürlich ist mein Bildschirm nicht so groß. Aber dafür gibt es ja die TScrollBox, in die man eine TPaintBox legt. Dann kann man die Paintbox schön groß machen und dann über die Grafik scrollen.
Die Daten, aus denen das Bild aufgebaut ist, liegen in Datenstrukturen vor und sind vom Bild völlig unabhängig. Aber daraus entstehen mitunter sehr große Grafiken ( Beispiel: www.entwickler-ecke....ownload.php?id=16395 ).
Ich habe gestern mal geschaut wie groß das mitunter werden kann und war selbst überrascht. Eine Grafik war 3.800 Pixel breit und 250.000 Pixel hoch. Nach etwas Multiplikation kam ich dann auf 950.000.000 Pixel. Bei 4 Byte pro Pixel käme ich auf ca. 4 GB. Tatsächlich belegt die Grafik aber "nur" 650 MB im RAM, was mich sehr verwundert.
Hat jemand dafür eine Erklärung?
Ich meine, habe irgendwann mal mit 32k RAM angefangen zu programmieren und nun das... Schon irgendwie witzig. :)
Horst_H
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1654
Erhaltene Danke: 244

WIN10,PuppyLinux
FreePascal,Lazarus
BeitragVerfasst: Fr 14.11.14 10:01 
Hallo,

Zitat:
Die Daten, aus denen das Bild aufgebaut ist, liegen in Datenstrukturen vor und sind vom Bild völlig unabhängig. Aber daraus entstehen mitunter sehr große Grafiken

Da frage ich mich doch, ob das Bild überhaupt komplett erzeugt werden muss, sondern nicht einfach in passenden Teilen, das es nur aus kleinen Bildern und Linien besteht.Zum Beispiel in 3x3 Scrollboxgröße und zuerst die Mitte angezeigt wird und bei drohendem Rauswandern die passenden 3 Felder/Kacheln ergänzen.
Du kannst ja in einer Liste zu jedem Feld/Kacheö die zugehörigen Objekte eintragen.
Alternativ könnte ja eine Kachel die volle Breite haben, die Höhe ist ja erheblich größer, und dann eben 3 Kacheln überenander.

Gruß Horst
Blup
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 174
Erhaltene Danke: 43



BeitragVerfasst: Fr 14.11.14 11:04 
user profile iconTastaro hat folgendes geschrieben Zum zitierten Posting springen:
Eine Grafik war 3.800 Pixel breit und 250.000 Pixel hoch. Nach etwas Multiplikation kam ich dann auf 950.000.000 Pixel. Bei 4 Byte pro Pixel käme ich auf ca. 4 GB. Tatsächlich belegt die Grafik aber "nur" 650 MB im RAM, was mich sehr verwundert.

Vermutlich hast du hast das Konzept nicht verstanden. Eine PaintBox speichert keine Daten, sie stellt lediglich einen Canvas zur Verfügung.
Der Canvas selbst kapselt einen Gerätekontext der GDI, ein Treiber der als Ausgabe dient.
Es werden lediglich Zeichenbefehle und die dazu nötigen Daten an das Gerät übermittelt.
Welche Farbtiefe zur Verfügung steht, wie die Zeichenbefehle umgesetzt werden, welche Daten das Gerät puffert, bleibt dem Treiber überlassen.
Ist das Gerät z.B. ein Drucker, kann man die gezeichneten Pixel bei vielen Treibern überhaupt nicht auslesen.

Für den Canvas ist eine Region festgelegt, die den Ausgabebereich einschränkt (siehe ClipRect), z.B. auf den sichtbaren Bereich deines Fenster.
Der Buffer wird also nie größer sein, als dieser Bereich.

Für deine Grafik brauchst du nicht unbedingt eine riesige Bitmap. Es genügt wenn du dir die Objekte und deren Position merkst z.B.

Leitung(x1, y1, x2, y2)
Diode (x1, y1, x2, y2)
Schalter(x1, y1, x2, y2, aus)
usw.

Im OnPaint des Canvas zeichnest du alle Objekte, die innerhalb von ClipRect liegen.

Für diesen Beitrag haben gedankt: Tastaro
Tastaro Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 414
Erhaltene Danke: 23



BeitragVerfasst: Fr 14.11.14 11:19 
Hallo Blup,

vielen Dank. Du hast mir mit Deinen Ausführungen sehr geholfen. Ich dachte die ganze Zeit, dass die Paintbox so viel Speicher benötigt. Durch Deine Erklärung bin ich nun auf die Idee gekommen das mal zu verifizieren. Dabei habe ich festgestellt, dass meine Datenstrukturen, die der Zeichnung zugrunde liegen, die eigentlichen Specherfresser sind. Damit habe ich nun einen Punkt, wo ich optimieren kann.