[gelöst] Wieviel Image/Bild verträgt eine Anwendung?

[Erwin]

Hallo Zusammen.

Man kann ja während der Erstellung/Programmierung in den Images von Anfang an ein Bild laden. Das Praktische daran ist ja, dass diese Bild dann in der Anwendung ist. Man muss also das Image bzw. Bild nicht mehr extra mit dazu Kopieren, Verschicken etc. Anders wenn man Bilder während die Anwendung läuft (nach) lädt.

Nun würde es mich interessieren, wie viel verträgt so eine Anwendung an Bild? Bilder? Bis zu 10 MB? Oder spielt vor allem die Pixel-Größe eine Rolle? Macht es einen Unterschied (von der Betrachtungsmöglichkeit mal abgesehen) ob ein Image so groß wie das Bild ist, oder darf ... sollte die Image-Darstellung wenn möglich kleiner sein als das Bild selbst?
Und wirken sich diese Bilder auch auf den nötigen Arbeitsspeicher 1:1 aus? Oder gar mehr?

Danke. Weil ich wüsste jetzt leider nicht, wie ich das selbst vernünftig teste könnte, was vor allem die Inneren Auswirkungen betrifft.

Gruß, Erwin.

[wp_xyz]

Mit "Image" meinst du TImage-Instanzen, oder z.B. als TBitmap geladene Bild-Dateien? Generell würde ich die Zahl der Komponenten (also TImages) eher gering halten. Gab es da nicht mals sowas wie Maximalzahl von Handles? Es gibt einige Forumsbeiträge, bei denen die User über lahmende Anwendungen klagen, wenn eine größere Zahl von Komponenten auf dem Formular ist. Bitmaps dagegen kannst du so viele wie der Speicher zulässt laden. Nach Möglichkeit in der Größe laden, in der das Bild gebraucht wird, also keine 100-Megapixel-Bild der neusten Super-Kamera zu einem 128x128 Pixel großen Icon schrumpfen. Wenn du viele gleich große Bilder brauchst, kannst du die Bilder auch in eine Imagelist laden. TBitBtn, TSpeedButton, TToolButton, TMenuItem, ab Laz3.0 auch TImage haben ein Property Images, in dem man eine ImageList einhängen kann; das Bild wird dann mittels ImageIndex ausgewählt.

[m.fuchs]

Grundsätzlich würde ich keine Bilder direkt im TImage ablegen (außer es sind wirklich wenige und kleine, zum Beispiel zwei Logos in 200x200px) - sondern lieber Ressourcen verwenden.
Warum? Um Arbeitsspeicher zu sparen. Die Ressourcen werden nämlich nur bei Bedarf geladen.

Hier ein paar Werte aus einem minimalen Test unter Linux.

Anwendung mit einem leeren Form: RAM-Bedarf knapp 30 MiB
Anwendung mit zehn TImages, in die jeweils ein PNG mit 2,1 MiB geladen wurde: RAM-Bedarf über 230 MiB
Anwendung mit einem TImage und zehn PNG (2,1 MiB) als Ressourcen: RAM-Bedarf knapp 30 MiB

Willst du also mehrere Bilder im Programm vorhalten, aber nicht immer alle anzeigen fährst du mit Ressourcen besser. Die werden erst bei Bedarf aus der ausführbaren Datei geladen.

Das ist jetzt natürlich nur ein grober Test, gerade unter Linux kann man beim Thema Speicherverwaltung und wieviel wird wirklich belegt ganze Bücher verfassen. Aber als Anhaltspunkt ist es sicher verwendbar.

[Erwin]

Danke für Eure Antworten.

Mit "Image" meinst du TImage-Instanzen, oder z.B. als TBitmap geladene Bild-Dateien? Generell würde ich die Zahl der Komponenten (also TImages) eher gering halten. Gab es da nicht mals sowas wie Maximalzahl von Handles? Es gibt einige Forumsbeiträge, bei denen die User über lahmende Anwendungen klagen, wenn eine größere Zahl von Komponenten auf dem Formular ist. Bitmaps dagegen kannst du so viele wie der Speicher zulässt laden. Nach Möglichkeit in der Größe laden, in der das Bild gebraucht wird, also keine 100-Megapixel-Bild der neusten Super-Kamera zu einem 128x128 Pixel großen Icon schrumpfen. Wenn du viele gleich große Bilder brauchst, kannst du die Bilder auch in eine Imagelist laden. TBitBtn, TSpeedButton, TToolButton, TMenuItem, ab Laz3.0 auch TImage haben ein Property Images, in dem man eine ImageList einhängen kann; das Bild wird dann mittels ImageIndex ausgewählt.

Ja, meine damit TImage-Komponente. Und das Bild als PNG, weil diese weniger Speicherplatz brauchen. Kann es aber dafür sein, dass PNG mehr Arbeitsspeicher braucht, um die (teils gepackten?) Bilder dar zu stellen, im Gegensatz zu BMP?
Vor über 25 Jahren habe ich mit Delphi 2 ein Programm mit 50 ComboBoxen geschrieben ... das hat sich damals aufgehängt. Heute vertragen die ja zum Glück mehr.
Aber betrifft das nur die Komponenten, oder auch wenn es um Arrays, Record und Co. geht?
ImageList? Kann mich dunkel daran erinnern, dass es zum einem mit PNG Probleme gab, was das Transparent angeht, was ich ebenfalls brauchen würde. Und glaube, die Ausführbare Datei war dann auch um einiges Größer, als wenn man TImage nutzt. Anderseits habe ich damals nicht überprüft, wie es wiederum dafür mit dem Arbeitsspeicher aussieht? Was ja auch oder je nach dem weit aus mehr von Bedeutung sein kann, oder gar ist.

Grundsätzlich würde ich keine Bilder direkt im TImage ablegen (außer es sind wirklich wenige und kleine, zum Beispiel zwei Logos in 200x200px) - sondern lieber Ressourcen verwenden.
Warum? Um Arbeitsspeicher zu sparen. Die Ressourcen werden nämlich nur bei Bedarf geladen.

Hier ein paar Werte aus einem minimalen Test unter Linux.

Anwendung mit einem leeren Form: RAM-Bedarf knapp 30 MiB
Anwendung mit zehn TImages, in die jeweils ein PNG mit 2,1 MiB geladen wurde: RAM-Bedarf über 230 MiB
Anwendung mit einem TImage und zehn PNG (2,1 MiB) als Ressourcen: RAM-Bedarf knapp 30 MiB

Willst du also mehrere Bilder im Programm vorhalten, aber nicht immer alle anzeigen fährst du mit Ressourcen besser. Die werden erst bei Bedarf aus der ausführbaren Datei geladen.

Das ist jetzt natürlich nur ein grober Test, gerade unter Linux kann man beim Thema Speicherverwaltung und wieviel wird wirklich belegt ganze Bücher verfassen. Aber als Anhaltspunkt ist es sicher verwendbar.

Danke für die Daten. Für mich ist es etwas schwer den RAM-Bedarf heraus zu finden. Leider scheint es bei Lazarus keine einfaches Programm bzw. Code-Zeilen zu geben, das einem den RAM-Bedarf mit teilt.
Bin aber etwas verwirrt. Während das mit den 10 Images, im Schnitt jedes Images dann 20 MiB Arbeitsspeicher braucht ... also fast 10 Fache was die Bildgröße selbst betrifft, braucht das TImage als Ressource nicht mal ... 0? Sollte es nicht zumindest ein mal 20 MiB sein?
Wie ist das Überhaupt mit Bild als Ressourcen gemeint? Wäre das etwa, wenn man es, wie xyz meinte, in die TImageList packt?
Hm... ok, werde jetzt erst mal selber auch im Forum mal danach suchen.

[wp_xyz]

Und das Bild als PNG, weil diese weniger Speicherplatz brauchen. Kann es aber dafür sein, dass PNG mehr Arbeitsspeicher braucht, um die (teils gepackten?) Bilder dar zu stellen, im Gegensatz zu BMP?

Nur auf der Platte. Wenn das Bild in ein TImage geladen ist, ist es dekomprimiert. Bin nicht sicher, ich glaube auch, wenn es als TPortableNetworkgraphic schon geladen ist, ist es auch schon komprimiert. Nur wenn es als Resource, quasi als Datei, in die exe eingebunden ist, bleibt es komprimiert, wird aber später beim Gebrauch natürlich auch wieder ausgepackt und entsprechend größer.

Vor über 25 Jahren habe ich mit Delphi 2 ein Programm mit 50 ComboBoxen geschrieben ... das hat sich damals aufgehängt. Heute vertragen die ja zum Glück mehr.
Aber betrifft das nur die Komponenten, oder auch wenn es um Arrays, Record und Co. geht?

Naja, Delphi 2 solltest du nicht mehr als Vergleichsmaßstab heranziehen, da hat sich einiges geändert. Was meinst du mit "Arrays, Record und Co."? Also ein drei-dimensionales Integer-Array mit 1024 Werten in jeder Dimension braucht 1024x1024x1024*4 = 4 GB Speicher. In einer 32-Bit Anwendung geht das nicht mehr, aber in einer 64-Bit-Anwendung kann das je nach Speicherausbau deines Rechners funktionieren

ImageList? Kann mich dunkel daran erinnern, dass es zum einem mit PNG Probleme gab, was das Transparent angeht, was ich ebenfalls brauchen würde.

Wieder so eine Delphi2-Erfahrung? Vergiss das, Lazarus kann damit hervorragend umgehen

Ausführbare Datei war dann auch um einiges Größer, als wenn man TImage nutzt.

Es kommt der Code der ImageList dazu, natürlich, aber soooo viel sollte das auch nicht sein. Und wenn du ein Menü oder eine Toolbar verwendest, die eine ImageList intern verwenden, ist die ImageList eh schon drin. Wenn es dir auf das letzte Byte ankommt, musst du auf GUI und Bilder verzichten.

[Erwin]

Nur auf der Platte. Wenn das Bild in ein TImage geladen ist, ist es dekomprimiert. Bin nicht sicher, ich glaube auch, wenn es als TPortableNetworkgraphic schon geladen ist, ist es auch schon komprimiert. Nur wenn es als Resource, quasi als Datei, in die exe eingebunden ist, bleibt es komprimiert, wird aber später beim Gebrauch natürlich auch wieder ausgepackt und entsprechend größer.

Das müsste ich dann (noch) mal testen. Habe da eher schwach in Erinnerung, dass die Anwendung ziemlich gleich um die Größe des Bildes (PNG) angewachsen ist, und nicht mehr.

Naja, Delphi 2 solltest du nicht mehr als Vergleichsmaßstab heranziehen, da hat sich einiges geändert. Was meinst du mit "Arrays, Record und Co."? Also ein drei-dimensionales Integer-Array mit 1024 Werten in jeder Dimension braucht 1024x1024x1024*4 = 4 GB Speicher. In einer 32-Bit Anwendung geht das nicht mehr, aber in einer 64-Bit-Anwendung kann das je nach Speicherausbau deines Rechners funktionieren

Was mit Array und Co. meinte: Wenn ich jetzt statt Buttons ein Image nehme, und dann mittels Array (TRect) feststelle, wo ich hin geklickt habe. Ob man dann mittels Arrays (TRect) locker 1000 Felder dann machen kann, während wenn man Buttons und Co. nehmen würde, der Prozessor und BS jammern würden. Aber jetzt wo ich es schreibe ... scheint mir Buttons mehr vom Computer abzuverlangen ... während das andere vor allem mehr vom Programmierer.

ImageList? Kann mich dunkel daran erinnern, dass es zum einem mit PNG Probleme gab, was das Transparent angeht, was ich ebenfalls brauchen würde.

Wieder so eine Delphi2-Erfahrung? Vergiss das, Lazarus kann damit hervorragend umgehen

Leider nein, nur die 50 Combobox. Alles andere ist schon Lazarus/FP. Ist vielleicht gerade mal 4 Jahre her. Anderseits eben 4 Jahre ... kann mich nicht mehr so ganz daran erinnern. Muss es also wohl selbst wieder neu testen.

Es kommt der Code der ImageList dazu, natürlich, aber soooo viel sollte das auch nicht sein. Und wenn du ein Menü oder eine Toolbar verwendest, die eine ImageList intern verwenden, ist die ImageList eh schon drin. Wenn es dir auf das letzte Byte ankommt, musst du auf GUI und Bilder verzichten.

Damals, vor 4 Jahren, habe ich nicht so sehr darauf geachtet, ob Pro Bild die Anwendung um vieles größer wurde (also zb. Bild 1 MB, Anwendung statt diese 1 MB dann 1,1 MB mehr) oder ab dies nur einmalig eines ImageList der Fall war? Auch sonst waren es damals kleine Bilder, so dass es schwer abzuschätzen war, ob es generell xx% des Bildes aus machte, oder eben für jedes Bild zu der Bildgröße noch mal xx KB unabhängig von der Bildgröße dazu kam?

Hm... die Auswirkung von Bildern auf die Größe der EXE-Anwendung zu testen ist zum Glück kein Problem.
Wie viel Arbeitsspeicher es dann braucht ... wird für mich dann komplizierter. Aber mal sehen. Sollt auch irgendwie gehen.

Insgesamt brauche ich mir aber scheinbar keine Sorgen machen, dass mal alles zusammenbricht, weil man es übertreibt? Kann man durchaus davon ausgehen, dass wenn z.B. der Arbeitsspeicher-Bedarf eine Bestimmte Grenze nicht überschreitet (zb. 500 MiB, bei 4 GB RAM), dass dann in so weit alles im Grünen Bereich ist?

Was ich mich vor allem aber fragte: Kann man den Daten dann auch so einfach trauen? Oder gibt es dann noch versteckte Probleme, wenn man es mit den Image in Anwendungen übertreibt? Ob also ab einen bestimmten Punkt eine Art Schleife los getreten werden könnte, die dann anderweitig Ärger macht? Ständig den CPU zb. über Gebühr beansprucht (weil er zb. dann ständig am verarbeiten/ständig-neu-darstellen der Bilddaten ist). Denn gerade dies schreckte mich vor größeren Testen ab. Auch, sollte so was der Fall sein, wäre dies dann generell eher Schädlich/Fragwürdig dies dann überhaupt so zu programmieren.

Tja, vieles hätte ich mir wohl doch selbst beantworten können. Aber es sind auch paar gute Anregungen und Infos von Euch dabei. Aber auch sonst fühle mich jetzt sicherer, wenn ich es auch von anderen lese. Danke.

[wp_xyz]

dass die Anwendung ziemlich gleich um die Größe des Bildes (PNG) angewachsen ist, und nicht mehr.

Was heißt "die Anwendung ist angewachsen"? Die Größe der exe-Datei oder der Speicherverbrauch? Wie willst du letzteren überhaupt messen?

Die Größe der exe-Datei nimmt natürlich um die Größe des Bilddatei zu - irgendwie muss das Ding ja in der Exe gespeichert werden -, wenn nicht sogar um mehr. Bei TImage vermute ich um den Faktor 2, weil in der lfm-Datei die binären Bytes der Bilddaten als Ascii-Text gespeichert sind (also statt 1 Byte für z.B. FF zwei Bytes für den String 'FF'). Nur wenn die Graphik als Resource gespeichert ist, sollte die Datei 1:1 enthalten sein (so grob wenigstens)

Der Speicherverbrauch wird dagegen, sobald das TJpegImage oder was auch immer geladen ist, deutlich anwachsen, weil das Bild dann entpackt im Speicher liegt als Pixelmatrix von üblicherweise Breite x Höhe x 4 Byte, und die 2 MB des jpeg-komprimierten Fotos von 3000x2000 Pixeln haben sich auf 22 MB aufgebläht.

[m.fuchs]

Danke für die Daten. Für mich ist es etwas schwer den RAM-Bedarf heraus zu finden. Leider scheint es bei Lazarus keine einfaches Programm bzw. Code-Zeilen zu geben, das einem den RAM-Bedarf mit teilt.

Die meisten Betriebssysteme haben dafür Tools, im Code auswerten sehe ich für so einen Test keine Notwendigkeit.

Bin aber etwas verwirrt. Während das mit den 10 Images, im Schnitt jedes Images dann 20 MiB Arbeitsspeicher braucht ... also fast 10 Fache was die Bildgröße selbst betrifft, braucht das TImage als Ressource nicht mal ... 0? Sollte es nicht zumindest ein mal 20 MiB sein?

Nö, wenn das TImage leer ist - ich habe in dem Beispiel kein Bild reingeladen - braucht es nur sehr wenig Speicher. Das wollte ich mit dem Test ausdrücken, die Daten sind das Problem - nicht die TImage-Komponente selber.

Wie ist das Überhaupt mit Bild als Ressourcen gemeint? Wäre das etwa, wenn man es, wie xyz meinte, in die TImageList packt?

Nein, das bedeutet dass man Daten an die ausführbare Datei anhängen kann. So muss man nur eine Datei ausliefern, die alles enthält:

https://wiki.freepascal.org/Lazarus_Resources

[Erwin]

Was heißt "die Anwendung ist angewachsen"? Die Größe der exe-Datei oder der Speicherverbrauch? Wie willst du letzteren überhaupt messen?

Die der Exe. Es ging doch auch darum, ob die PNG Komprimiert oder entpackt dann in der Anwendung ist. Da es aber um die Größe der gepackten Bilddatei größer wurde, spricht vieles dafür dass es auch in der (nicht laufenden Anwendung) ebenfalls gepackt ist, also als PNG.

Danke für die Daten. Für mich ist es etwas schwer den RAM-Bedarf heraus zu finden. Leider scheint es bei Lazarus keine einfaches Programm bzw. Code-Zeilen zu geben, das einem den RAM-Bedarf mit teilt.

Die meisten Betriebssysteme haben dafür Tools, im Code auswerten sehe ich für so einen Test keine Notwendigkeit.

Ja, stimmt schon. Aber nebenbei Tools laufen zu lassen ... Aber Heutige BS sind da eigentlich ja auch stabiler. Dennoch, daran muss ich mich erst noch gewöhnen ... dieses hin und her ... und teils wichtiges Tool zugleich mit anderer Anwendung. Aber führt leider kaum ein Weg drum herum. Fand es praktischer, wenn es vom gleichen Programm (damals Delphi 2 und win95) direkt angezeigt wurde.

Nö, wenn das TImage leer ist - ich habe in dem Beispiel kein Bild reingeladen - braucht es nur sehr wenig Speicher. Das wollte ich mit dem Test ausdrücken, die Daten sind das Problem - nicht die TImage-Komponente selber.

Das erklärt einiges. Ich ging davon aus, dass zumindest eins aktiv sein würde, weil man ja eins normalerweise mind. braucht.

Nein, das bedeutet dass man Daten an die ausführbare Datei anhängen kann. So muss man nur eine Datei ausliefern, die alles enthält:

https://wiki.freepascal.org/Lazarus_Resources

Hört sich toll an, das mit dem anhängen. Tja ... diese Seite ... leider ist Englisch ... da sträubt es mich wegen schlechter Erfahrung innerlich. Für Programmierer zugegeben leider ungünstig, aber ist leider so. Und dann auch noch Art Technik-Englisch ... . Mal sehen ... .

Habe hier im Forum heraus gefunden, dass man scheinbar mittels 'Projekt -> Projekteinstellungen,' dort im Auftauchendem Fenster dann 'Projekteinstellungen -> Ressourcen' dann Dateien problemlos hinzu fügen kann? Aber vor dem Kompilieren noch Rechts die Art der Datei auswählen. Diese Einstellung ist scheinbar auch nur an dem einen Projekt dann gebunden.
Mal sehen, vielleicht finde ich hier noch irgendwo heraus, wie man diese dann im Programm lädt.

[m.fuchs]

Habe hier im Forum heraus gefunden, dass man scheinbar mittels 'Projekt -> Projekteinstellungen,' dort im Auftauchendem Fenster dann 'Projekteinstellungen -> Ressourcen' dann Dateien problemlos hinzu fügen kann? Aber vor dem Kompilieren noch Rechts die Art der Datei auswählen. Diese Einstellung ist scheinbar auch nur an dem einen Projekt dann gebunden.
Mal sehen, vielleicht finde ich hier noch irgendwo heraus, wie man diese dann im Programm lädt.

Genau, hier mal ein Beispiel für ein PNG welches in hinzugefügt habe.

resources.png (74.75 KiB) 417 mal betrachtet

Um es dann in ein TImage zu laden, reicht dieser Code:

Code: Alles auswählen

Image1.Picture.PNG.LoadFromResourceName(HInstance, 'MEIN_BILD_01');

[af0815]

Ich definiere es mal generell neutral: Ein Programm verträgt jede Menge Bilder, Buttons etc. - Was es nicht verträgt, Programmierer die damit nicht umgehen können

Es ist jetzt einmal zu überdenken, was du wirklich anzeigst. Ich kann mir kein Formular aus 1000 Buttons (oder den Ersatz mit Images) vorstellen. Das ist ganz einfach nicht sinnvoll als Oberfläche für den Benutzer. Speicherplatz ist auf PCs kein Problem, auf uPs schon. Ich gehe davon aus, das du auf Windows unterwegs bist, alleine wegen dem Vergleich mit Delphi 2. Mit der Erfahrung bist du genaugenommen im DOS mit grafischen Erweiterungen steckengeblieben (Win95 ist rein DOS basierend mit draufgestülpter GUI). Bei Delphi ist es erst ab der Version 5 bzw. 7 so richtig vergleichbar losgegangen. Lege Delphi 2 mal geistig auf die Seite, vieles was dort noch nötig war ist jetzt ganz anders gelöst. Lazarus kann man mit Versionen ab Delphi 7 erst wirklich vergleichen anzufangen.

Bilder etc. so kann man sagen, gehören entweder in die Resourcen oder extra behandelt, auf jedenfalls nachladen ist angesagt. Dafür wurden die Resourcen auch geschaffen. Bei extra behandeln, ist es am besten sich auch wegen eines Installers was zu überlegen, bei Windows ist das InnoSetup sehr weit verbreitet (Übrigends in Delphi geschrieben).

Was man auch im Kopf haben muss, du hast eine gewisse initiale Größe der ausführbaren Datei, die se wächst aber ab einen Zeitpunkt nicht mehr wesentlich, auch wenn der Code massiv größer wird. Das ist dem Effekt geschuldet, das sowohl die VCL bei Delphi, wie die vergleichbare LCL (und FCL) bei Lazarus/FPC eine mindest Codebasis am Anfang ins Projekt bringen. Das ist normal und wenn man in den Foren sucht findet man jede Menge Diskussionen und Erklärungen dazu.

Das man mit englisch am Kriegsfuß steht, muss man sich als Programmierer leider abschminken. Du kannst aber für sehr viele Problemstellungen Bücher/Unterlagen für Delphi 7 (ev. auch 5) heranziehen, solange due nicht tiefer in zb: Datenbanken gegriffen wird. Da gibt es sehr viel Literatur, die auf deutsch ist. In der Lazarus Wiki ist zu beachten, das die Artikel (besonders auf deutsch) nicht unbedingt dem Letztstand entsprechen, trotzdem aber sehr gut sind. Wenn du Fragen hast, weil du etwas aus dem Internet probierst und es funktioniert nicht, so gib bitte auch die Quelle an.

Vor allen, schreib mal einfache Programme, wo du was austesten kannst und vor allen, wie sich etwas verhält. Bevor du dein eigentliches Projekt angehst. Vor allen, wenn die Testprogramme einfach sind, kann man die hier veröffentlichen und mit dem Beispiel kann man leichter helfen. Ja und auch Sourcecodeverwaltung ist heutzutage ein Thema (zB. GIT). Wenn man sich früh daran gewöhnt, hat man weniger Ärger später am Hals (auch beim privaten Programmieren)

[Erwin]

Code: Alles auswählen

Image1.Picture.PNG.LoadFromResourceName(HInstance, 'MEIN_BILD_01');

Liest sich ja ganz einfach. Typ: RCDATA? Nicht Bitmap?
Danke. Überhaupt Super das Ganze. Scheint genau das zu sein, was ich gesucht habe.

Ich definiere es mal generell neutral: Ein Programm verträgt jede Menge Bilder, Buttons etc. - Was es nicht verträgt, Programmierer die damit nicht umgehen können

Wer kann das schon? Lies mal die meisten der Bücher zum Programmieren. Deren Beschreibungen, Beispiele etc. sind einfach total schlechter Still bis hin zu totalem Mist. Leider. Es gibt nur wenige Ausnahmen davon. Und selbst diese befassen sich nicht sonderlich damit, wie übersichtliche Programmierung (wo sollt was wie hingeschrieben werden)aussehen soll. Mit Sicherheit habe ich oft Records und Array an Stellen ... eingeführt, erstellt, naja, eben ... wo sie nicht in dieser oder gar überhaupt nicht hingehören. Aber nach dem Motto: Es funktioniert, eben dort sind. Weil ... ich fand eben keine Lektüre die sich damit befasst. Dafür liest man um so mehr, dass man Array, Typen, Records überall hinschreiben kann. Toll ... . Von anderen wichtigen Tipps ganz zu schweigen.

Es ist jetzt einmal zu überdenken, was du wirklich anzeigst. Ich kann mir kein Formular aus 1000 Buttons (oder den Ersatz mit Images) vorstellen. Das ist ganz einfach nicht sinnvoll als Oberfläche für den Benutzer. Speicherplatz ist auf PCs kein Problem, auf uPs schon. Ich gehe davon aus, das du auf Windows unterwegs bist, alleine wegen dem Vergleich mit Delphi 2. Mit der Erfahrung bist du genaugenommen im DOS mit grafischen Erweiterungen steckengeblieben (Win95 ist rein DOS basierend mit draufgestülpter GUI). Bei Delphi ist es erst ab der Version 5 bzw. 7 so richtig vergleichbar losgegangen. Lege Delphi 2 mal geistig auf die Seite, vieles was dort noch nötig war ist jetzt ganz anders gelöst. Lazarus kann man mit Versionen ab Delphi 7 erst wirklich vergleichen anzufangen.

Der Vergleich von Delphi 2 ist von damals, von vor über 25 Jahren ... aber ja, der Umstand dass dies das BS/PC in die Knie gezwungen hat, hat bis Heute Art Narben hinterlassen. Bin halt ständig davor auf der Hut, ob ich nicht auch Heute noch fertig bringen könnte, einen Programm versehentlich zu viel zu zu muten.
Was Windows betrifft: Seit ca. 12 Jahren nutzte ich Windows nur noch zum Spielen (also wegen den Spielen für Win). Seit fast 2 Jahren gar nicht mehr. Mein PC ging damals kaputt. Linux lief im neuen PC einfach weiter. Windows weigerte sich total. Und eine Neuinstallation von Win ... NEEE!! Es gibt angenehmere Methoden sich zu quälen.
Und was die 1000 Buttons betrifft, das war ein Extrem-Beispiel, und meine Neugier was in solchen Extremen dann besser wäre, oder ob das Andere auch Ärger machen könnte. Meine Überlegungen gehen eh eher in die Richtung, dass man z.B. Statt die Seite zu wechseln, wo dann ebenfalls viele Buttons sind, die Überschrift geändert wird, und auf Grund der anderen Überschrift der Button dann was anderes ausführt. Naja, eigentlich will ich sogar vieles in EIN Image rein packen, sozusagen. Will auch keine Datenbanken programmieren, sondern Spiele. Deshalb auch die etwas anderen Ansprüche.

Bilder etc. so kann man sagen, gehören entweder in die Resourcen oder extra behandelt, auf jedenfalls nachladen ist angesagt. Dafür wurden die Resourcen auch geschaffen. Bei extra behandeln, ist es am besten sich auch wegen eines Installers was zu überlegen, bei Windows ist das InnoSetup sehr weit verbreitet (Übrigends in Delphi geschrieben).

Das sehe ich ja auch so. Deshalb ja den Thread von mir, um Tipps dazu zu erhalten, welche ich auch bekommen habe. Leider wird so was wichtiges ja meist tot geschwiegen bzw. in Büchern selten darüber geschrieben. Und wenn doch, dann so, dass es schwer ist, zu verstehen.

Das man mit englisch am Kriegsfuß steht, muss man sich als Programmierer leider abschminken. Du kannst aber für sehr viele Problemstellungen Bücher/Unterlagen für Delphi 7 (ev. auch 5) heranziehen, solange due nicht tiefer in zb: Datenbanken gegriffen wird. Da gibt es sehr viel Literatur, die auf deutsch ist. In der Lazarus Wiki ist zu beachten, das die Artikel (besonders auf deutsch) nicht unbedingt dem Letztstand entsprechen, trotzdem aber sehr gut sind. Wenn du Fragen hast, weil du etwas aus dem Internet probierst und es funktioniert nicht, so gib bitte auch die Quelle an.

Ich versuche mich ja deshalb (nicht nur deshalb) immer wieder durch zu beißen. Aber ... man hat mich damals mit THE (der richtigen Aussprache) genervt. Und 3 Englisch-Lehrer in 3 Jahren. Kaum war der eine mit meinen THE zufrieden und kaum hatte ich Ihn auch gut verstanden (bin leicht schwerhörig), ging das Ganze mit dem nächstem vom neuen los. Alle die bereits bekannten englischen Wörter hörten sich dann anders an ... .
Achja, habe ein Buch über Delphi 7. Ohne dem würde ich ja noch viel banalere Fragen stellen. Dennoch danke für den Tipp. Bin also alles andere als der Einzige, der lieber ein gutes Delphi-Buch für Lazarus/FP zu Rate zieht, als gar keins.

Vor allen, schreib mal einfache Programme, wo du was austesten kannst und vor allen, wie sich etwas verhält. Bevor du dein eigentliches Projekt angehst. Vor allen, wenn die Testprogramme einfach sind, kann man die hier veröffentlichen und mit dem Beispiel kann man leichter helfen. Ja und auch Sourcecodeverwaltung ist heutzutage ein Thema (zB. GIT). Wenn man sich früh daran gewöhnt, hat man weniger Ärger später am Hals (auch beim privaten Programmieren)

Äh .... ja. Mache ich ja. Bzw. wenn ich auf Probleme stoße, ein gezieltes Projekt zum testen. Aber manchmal fühle ich mich auch wohler, erst vorher zu fragen, damit ich besser Abschätzen kann, was ich an Test dem ganzen zumuten kann. Oder wie das mit dem Resourcen, um gute Tipps zu bekommen, in welche Richtung man sinnvollerweise testen sollte.

[m.fuchs]

Code: Alles auswählen

Image1.Picture.PNG.LoadFromResourceName(HInstance, 'MEIN_BILD_01');

Liest sich ja ganz einfach. Typ: RCDATA? Nicht Bitmap?

Wenn ich mich recht erinnere, ist BITMAP tatsächlich nur für Windows-Bitmap-Daten gedacht. Wie auch immer, RCDATA funktioniert jedenfalls - also ist es das richtige.

[af0815]

Will auch keine Datenbanken programmieren, sondern Spiele. Deshalb auch die etwas anderen Ansprüche.

Schau dir das auch mal an
https://wiki.freepascal.org/Game_Engine
https://wiki.freepascal.org/Choosing_a_Game_Engine

man muss nicht unbedingt eckige Räder neu erfinden. (BTW: Der Artikel ist geil mit dem Reifen https://t3n.de/news/youtuber-bastelt-ec ... n-1547228/ ) SCNR

[Erwin]

Wenn ich mich recht erinnere, ist BITMAP tatsächlich nur für Windows-Bitmap-Daten gedacht. Wie auch immer, RCDATA funktioniert jedenfalls - also ist es das richtige.

Stimmt, habe es jetzt getestet: RCDATA ist das richtige. Bei Bitmap jammert er nur herum.

Was mir vorhin gar nicht richtig aufgefallen ist: Das Ganze ohne der png-Endung. Etwas ungewohnt. Aber sonst jammer er ja.

Dabei habe ich 2 Dinge festgestellt: Scheinbar wächst der Speicherbedarf entsprechend dem Ausgepackten Bild-Zustand an. Bilder die weniger Platz benötigten, aber in der Darstellung gleich groß waren (x*y) benötigten dann gleich viel Speicher an MiB. Während ein kleineres Bild (in der x*y-Abmessung), das aber mehr Platz auf der Festplatte benötigte, dann weniger MiB brauchte als die anderen.
Und noch etwas, was ich nicht so schön finde: Die Anwendung wurde mehr als Doppelt so groß als die Bilder eigentlich Platz brauchten. So ca. 2,5 mal. Naja, diesen Abstrich muss ich dann halt hinnehmen.

Eigentlich hatte ich gehofft, dass man auch mit StringGrid so was dann laden kann. Also in dem Fall natürlich Datenbankdaten dergleichen. Aber dies hat leider keinen entsprechenden Befehl parat. Schade.

Will auch keine Datenbanken programmieren, sondern Spiele. Deshalb auch die etwas anderen Ansprüche.

Schau dir das auch mal an
https://wiki.freepascal.org/Game_Engine
https://wiki.freepascal.org/Choosing_a_Game_Engine

man muss nicht unbedingt eckige Räder neu erfinden. (BTW: Der Artikel ist geil mit dem Reifen https://t3n.de/news/youtuber-bastelt-ec ... n-1547228/ ) SCNR

Danke, vielleicht komme ich ich irgendwann darauf wieder zurück. Aber ... ich hatte mal eine Spiel-Engine (gekauft) ... schade um das Geld. Weil die haben eben zu viele Kanten. Manches kann man damit eben nicht machen, oder nur auf extrem Komplizierte Umwege. Da fühle ich mich mit einer Programmiersprache doch freier im Handeln. Damit kann ich mir teils meine eigene Engine basteln.