German Speicher-Problem mit blist-Library

D

Deleted member 103

Guest
Hallo,

ich habe ein Problem mit der Library "blist.dll" und zwar es geht darum das die Library den Speicher nicht frei gibt.

Im Anhang ist ein Test-Programm (habe ich von http://www.b4x.com/forum/official-updates/4881-blist-v0-9-beta-released-6.html#post30893 abgeleitet).

Wie ich getestet habe:
1) vor dem Start des Test-Programm mach ein Softreset(Specherauslastung ca. 24 MB)
2) Test-Programm mit dem Device-Id (VGA-Modus) starten und beenden(2 bis 3 x ausführen)
3) Speicherauslastung ca. 39 MB, weiter unten geht nicht mehr.

Auf mein MDA-Pro habe ich nur 49 MB frei d.h. ich kann fast nicht mehr damit arbeiten und bin wieder gezwungen ein Softreset durch zu führen.

Meine Frage: kann man das Test-Programm so ändern das beim beenden der Speicher wieder frei ist?


Ciao,
Filippo
 

Attachments

  • blist-v0-9-Test.sbp
    4.5 KB · Views: 334

corwin42

Expert
Licensed User
Longtime User
Hallo Filippo,

ich habe es jetzt nicht ausprobiert, aber folgendes dürfte funktionieren:

Wenn ich das richtig verstehe, kannst Du in der Device IDE das Programm nur 2-3 mal ausführen, bis der Speicher voll ist. Wenn Du die IDE einmal beendest dürfte dann aber wieder alles freigegeben werden, richtig?

Das Problem ist, dass die Methode des Zeichnens sehr viele "relativ große" Bitmaps benötigt. Bei Deinem Testprogramm halt 200 Stück. Bitmaps liegen ja im unmanaged Speicher bei .NET und werden deshalb von dem Garbage Collector nicht richtig aufgeräumt.

Was helfen könnte:
Da der Source von bList leider nicht verfügbar ist, kann ich hier erstmal nur raten. Wenn es gut implementiert ist, müsste es reichen, wenn Du beim Programmende die Items der Liste komplett mit list.Remove(index) entfernst. Ich vermute mal, dass dann ein dispose der Bitmaps gemacht wird. Falls das nicht klappen sollte, in einer Schleife mit bmp.Value = bItem.GetImage die Images jeweils in ein Bitmapobjekt holen und dann bmp.Dispose explizit aufrufen.

Ich hoffe, damit kommst Du klar.
 

JOTHA

Well-Known Member
Licensed User
Longtime User
Hallo Filippo,

... Test-Programm mit dem Device-Id (VGA-Modus) starten und beenden(2 bis 3 x ausführen) ...

Ich habe deine TestApp auf meinem Pocket-PC laufen gelassen, aber ein Softreset war auch nach 20 x starten und beenden nicht nötig. Ich habe einen HTC HD2 und der ist auch mit sehr viel (notwendigem und auch unnötigem) vollgepackt.

Mein Datenspeicher hat beim Start auch nur noch ca. 45 MB frei.

Evtl. liegt dein Problem gar nicht an der "bList.dll" ?

P.S.: Deine TestApp erscheint beim Start nur mit 1/4 der Auflösung, obwohl ich den Code im "Optimized Modus" und mit "Auto Scale" compiliert habe. Ist das bei Dir auch so?
 
D

Deleted member 103

Guest
@corwin42

Wenn ich das richtig verstehe, kannst Du in der Device IDE das Programm nur 2-3 mal ausführen, bis der Speicher voll ist. Wenn Du die IDE einmal beendest dürfte dann aber wieder alles freigegeben werden, richtig?
Leider wird der Speicher beim beenden der IDE auch nicht freigegeben.

Was helfen könnte:
Da der Source von bList leider nicht verfügbar ist, kann ich hier erstmal nur raten. Wenn es gut implementiert ist, müsste es reichen, wenn Du beim Programmende die Items der Liste komplett mit list.Remove(index) entfernst. Ich vermute mal, dass dann ein dispose der Bitmaps gemacht wird. Falls das nicht klappen sollte, in einer Schleife mit bmp.Value = bItem.GetImage die Images jeweils in ein Bitmapobjekt holen und dann bmp.Dispose explizit aufrufen.
das muss ich noch ausprobieren.

@JOTHA
P.S.: Deine TestApp erscheint beim Start nur mit 1/4 der Auflösung, obwohl ich den Code im "Optimized Modus" und mit "Auto Scale" compiliert habe. Ist das bei Dir auch so?
Ich verwende "Auto Scale" beim compilieren nie, weil ich beim programmieren immer, auf der PDA, beide auflösung testen möchte.
 

JOTHA

Well-Known Member
Licensed User
Longtime User
Hallo Filippo,

Ich habe jetzt mal wirklich lange mit deinem Beispiel herumexpermimentiert.

Ich finde deine Lösung, mit der ImageLibEx.dll zu arbeiten wirklich super, weil es dadurch möglich ist, viele Informationen (über den Weg "DrawerEx-String") in einem einzigen Item anzuzeigen.

Aber ich glaube genau darin liegt auch das Problem: So wie ich das verstehe ist die ImageLibEx.dll eigentlich für einen ganz anderen Zweck von agraham gemacht worden, nämlich für die Darstellung und Bearbeitung von grafischen Informationen, und die brauchen natürlich mehr Rechenpower als "nur Text".

Ich habe jedenfalls festgestellt, das selbst der Desktop-Rechner bei nur 50 Datensätzen schon deutlich länger braucht um alles darzustellen. Bei Dir waren das ja gleich mal 200 Datensätze. Das Ganze auch noch auf dem Pocket-PC, da ist der ganz schön am ackern.

--> Hier mal eine kurze Zwischenfrage: Die angezeigten Daten in der bList dienen an dieser Stelle nur der visuellen Information, oder? Jedenfalls habe ich keinen Weg gefunden, wie durch Anklicken des Items irgend eine Information weiterverarbeitet (ausgelesen) werden kann, oder gibt es da einen Weg? Ansonsten wäre der Weg über die ImageLibEx-Lösung ja eine Sackgasse (ab hier geht dann nichts mehr weiter ...).

Ich hoffe ich konnte dir mit meinen Gedanken etwas weiterhelfen, oder deine Überlegungen zumindest bestätigen.

Gruß von Gmünd nach Gmünd.
 
D

Deleted member 103

Guest
Hallo JOTHA,

--> Hier mal eine kurze Zwischenfrage: Die angezeigten Daten in der bList dienen an dieser Stelle nur der visuellen Information, oder? Jedenfalls habe ich keinen Weg gefunden, wie durch Anklicken des Items irgend eine Information weiterverarbeitet (ausgelesen) werden kann, oder gibt es da einen Weg? Ansonsten wäre der Weg über die ImageLibEx-Lösung ja eine Sackgasse (ab hier geht dann nichts mehr weiter ...).
schau dir mein Beispiel noch mal an, ich denke jetzt ist es so wie du es brauchst.

In mein Beispiel werden alle Einträge in variablen gespeichert, wenn es aber um Datenbank-Einträge geht muss du die ID von dem Datenbank-Eintrag speichern und dann über ein SQL-Comand den Eintrag aufrufen und darstellen.

Ciao,
Filippo
 

Attachments

  • blist-v0-9-Test.sbp
    4.4 KB · Views: 323

corwin42

Expert
Licensed User
Longtime User
@Filippo
Konntest Du das Speicherproblem eigentlich mittlerweile beheben bzw. finden? Wenn er nach dem Beenden der IDE den Speicher nichtmal freigibt, dann ist das aber irgendwie merkwürdig. Da würde ich dann Erel mal fragen.

Nochmal generell:
Wenn man die ListItems updated sollte man auf jeden Fall aufpassen, dass man das Image aus dem Item holt, und dieses dann wieder verändert bzw. mit ImageLibEx Funktionen bearbeitet (Andrew hat in den aktuellsten Versionen der ImageLibEx einen Mechanismus eingebaut, dass alte Images immer Disposed werden, wenn ein neues zurückgegeben wird).

BitMaps in .NET sind je nachdem, wie sie erstellt wurden "unmanaged" Speicherbereiche, d.h. sie werden vom Garbage Collector nicht mehr freigegeben, wenn alle Referenzen zu einem Image weg sind. D.h. man muss sehr genau aufpassen, dass man Images/BitMaps die nicht mehr benötigt werden schön mit Dispose entsorgt.

Will man meine Methode mit den Images für eine BList verwenden, sollte man aufpassen, dass die Liste nicht zu groß wird. Abgesehen davon, dass eine lange Liste im BList Objekt nicht mehr vernünftig zu bedienen ist (man scrollt sich dumm und dämlich) verbraucht sie halt eine Menge Speicher. Wenn man dennoch so eine lange Liste benötigt, sollte man sich vielleicht überlegen, nur die Items mit richtigem Inhalt zu füllen, die um den sichtbaren Bereich herum liegen und alle anderen mit einem (immer dem selben) Dummy Image. Wenn dann gescrollt wird, müsste man halt wieder Items, die "zu weit weg" sind mit dem Dummy-Image belegen und andere Items korrekt rendern. So ungefähr macht das PocketTwit z.B. auch in seiner Liste. Damit könnte man das Speicherproblem etwas eingrenzen. Erhöht natürlich den Programmieraufwand.

Gruß,
 
D

Deleted member 103

Guest
Hallo corwin42,

leide habe ich mein Speicherproblem nicht ganz gelöst.

Was helfen könnte:
Da der Source von bList leider nicht verfügbar ist, kann ich hier erstmal nur raten. Wenn es gut implementiert ist, müsste es reichen, wenn Du beim Programmende die Items der Liste komplett mit list.Remove(index) entfernst. Ich vermute mal, dass dann ein dispose der Bitmaps gemacht wird. Falls das nicht klappen sollte, in einer Schleife mit bmp.Value = bItem.GetImage die Images jeweils in ein Bitmapobjekt holen und dann bmp.Dispose explizit aufrufen.
Mit dein Tip ist nur etwas besser geworden.
Ich denke das ganze könnte nur gelöst werden wenn man die möglichkeit hätte mehrere Texte in verschieden positionen eingeben zu können.

z.B.:
Anzahltexte= 4
oText(0).location= New System.Drawing.point(0,0)
oText(1).location= New System.Drawing.point(100,0)
oText(2).location= New System.Drawing.point(0,20)
oText(3).location= New System.Drawing.point(100,20)

oText(0).text="Test 1"
oText(1).text="Test 2"
oText(2).text="Test 3"
oText(3).text="Test 4"

Somit könnt man auf die Bitmaps verzichten.


Grüße aus Schwäbisch Gmünd,
Filippo
 

JOTHA

Well-Known Member
Licensed User
Longtime User
Hallo Filippo,

wie gesagt, ich habe jetzt auch einiges ausprobiert.

Wenn ich die bList OHNE die ImageLibEx benutze, läuft alles flüssig und es gibt keine Speicherprobleme. Allerdings bleibt man da eben auf eine Zeile Text und ein Image pro Item beschränkt.

Deine lösung ist da schon viel umfangreicher in den Möglichkeiten, leider habe ich jetzt auch die Meldung "Out of Memory" schon auf dem Display gehabt.
 
D

Deleted member 103

Guest
Hallo jungs,

ich glaube für mich die Lösung gefunden zu haben. Ich verwende dafür nicht mehr die bList-Library und mein Speicherproblem ist weg.:)

Auf dem PPC läuft die Anzeige zwar nicht mehr so flüssig aber dafür, wenn man die Anwendung beendet, ist der Speicher wieder frei.

PS. vielleicht finded jemaden eine Lösung damit die Anzeige flüssiger läuft.


Ciao,
Filippo
 

Attachments

  • blist-v0-9_test.sbp
    4.4 KB · Views: 322
Top