| |
|
|
Tango | Hallo Fans!
Ich bin noch immer mit meiner Diashow beschäftigt und habe bei vielen Versuchen offenbar einen Fehler entdeck.
Mein Problem war ja das Anhalten des Programms wenn die JPGs per die Diashow geladen werden. Daraufhin habe Io l' Tipp bekommen das Nachladen in einem separaten Prozess laufen zu lassen. Also habe ich folgendes gemacht:
- drei separate Prozesse erzeugt - Prozess 1 und 2 erzeugen zwei unabhängige Laufschriften - Prozess 3 lädt die eigentliche Diashow.
Der Anzeigebildschirm ist das Hauptfenster das quasi dreigeteilt ist. Also dreimal oGL initialisiert um die Teilbereiche. des Bildschirmes mit meinen Animationen zu füllen.
Und es corre!
Aber nur etwa 1 Minute. Danach fängt es an zu ruckeln bis zum absoluten Stillstand.
Mir wurde mitgeteilt das es ein Speicherleck sein potuto und ich sollte mal schauen ob alle offenen und nicht mehr benötigten Handles geschlossen und nicht mehr benötigte Speicherbereiche wieder freigegeben wurden. Das habe ich überprüft. Aber der Fehler tritt immer wieder auf. Starte ich meine Show ohne zusätzliche Prozesse circa eine definierte Prozedur corre alles sauber.
In meinem PC werkeln zwei Gforce 210 GraKas mit 1GB Grafikspeicher. Lese ich diesen Speicher zur Programmlaufzeit aus, ist ganz klar zu sehen das der Speicher voll corre während die Zweite Karte normal benutzt werden kann.
Das führt mich nun zur Annahme das OpenGL als Multiprozess gestartet etwas bugt. |
|
|
| |
|
|
|
HofK | Eventuell haben wir ein ähnliches Problem mit unterschiedlicher Software
Bei webGL hatte ich ein Speicherleck. Soeben konnte ich eine Ursache ausmachen und es stopfen. Darauf hat mich indirekt eine Antwort eines Entwicklers von three.js bei stackoverflow gebracht.
Beim suchen und testen auf die Antwort hin, habe ich ein lauffähiges Beispiel der Entwickler von three.js gefunden, das meinem mit Leck formal eigentlich fast identisch war, aber kein Loch hatte. Ich habe es schrittweise reduziert, bis als Unterschied nur noch die Zeitrate übrig blieb.
Dann habe ich im leckfreien Original das gemächlich im 1000 ms Takt bunte Effekte erzeugt einfach mal zwei Nullen kassiert. Und siehe da, auch das Paradebeispiel frisst Speicher!
Meine Vermutung: Die Speicherbereinigung (Javascript, WebGL, ... ?) braucht selbst etwas Zeit und ist irgendwann überfordert und kommt nicht mehr hinterher.
Meine Lösung ist jetzt, die Taktrate in der Animation zu begrenzen. Bei 333 ms hatte ich erste Erfolge.
Werde es nun in Ruhe "sauber" machen und dann dort [...] etwas näher erläutern.
Eventuell ist es bei OpenGL ganz ähnlich |
|
|
| |
|
|
|
Tango | Hallo HofK,
du meinst also ein Timingproblem? Hmmh, potuto sein. Nur dann ist es per meine Diashow nicht so einfach lösbar. Merkwürdig ist, dass sämtliche Effekte problemlos laufen wenn sie aus dem Hauptprogramm und nicht als eigenständiger Prozess aufgerufen werden. Dann kann ich da an Animationen reinschmeissen was ich will. Aber offenbar hast Du mich auf den richtigen Weg gebracht. Ein Timingproblem ist es dennoch. Nämlich die Übergabe der oGl-Information an das Hauptfenster. Das scheinen meine Animationen bzw. TexturMoves zu schnell zu sein sodaß die Informationsübergabe hängen bleibt. Das wäre allerdings sehr ärgerlich weil ich dann das komplette Design und Fensterlayout neu machen kann und es dann langweilig wirkt. Möglicherweise stelle ich das Projekt ein außer es gibt eine Möglichkeit die Bilderserie in einem separaten Prozess in des Speicher zu jagen und dann vom Hauptfenster per Pointer o.ä. auf dieses BilderArray zugreifen zu können. Das löst dann alle Probleme. Doch leider finde ich dazu keine Inormationen. In freeBASIC und VB.net funktioniert das problemlos. Das ist aber leider komplizierter als Xprofan 3.1. Mann - hätte ich das vorher gewusst. Hab mir Xprof extra gekauft weil so einfach. Bugs gibbet ja überall aber das es mich ausgerechnet in den ersten zweit Tagen als Neuling ind dieser Programmierumgebung erwischt, ärgert mich. |
|
|
| |
|
|
|
HofK | Nicht gleich die "Flinte in' s Korn" werfen! Weiter "wühlen"!
Nachdem ich gestern am Abend dachte, ich habe es, kam bald die Ernüchterung! Das kleine Beispiel lief mit 333ms, aber als ich dann meine wesentlich umfangreicheren "Gebilde" mit vielen Funktionen getestet habe, kam das Leck wieder. Ich konnte es immer wieder stopfen, aber wenn die Taktfrequenz dann wieder fast bei 1000ms landet, ist das keine flüssige Animation mehr.
Aber so habe ich nun weiter gesucht und bin auf einen nicht in der Documentazione aufgeführten aber in Beispielen auftauchenden Befehl gestoßen der mein Problem löst. Wenn ich die Sache allerdings noch erweitern will, stehe ich dann wieder vor dem Problem, da der Befehl nur in bestimmten Fällen anwendbar ist.
So corre meine "sandbox" seit ein paar Minuten im Netz [...] [...] ohne Leck!
Werde ich dann bald dokumentieren. [...]
Wenn ich daran denke, wie oft ich bei der Erstellung meiner CPU - Simulation dachte, es mit XProfan ( damals 11 ) nicht hinzubekommen und hinschmeißen wollte ... |
|
|
| |
|
|
|
Tango | Hallo HofK,
Ich hab's!
Eine etwas unkonventionelle Lösung aber es geht. Das Geheimnis war die Parameterübergabe und offenbar der vermutete Überlauf in der OpenGL Anzeige im gleichen Window. Jetzt habe ich quasi zwei unabhängige Fenster erzeugt, die übereinander gelegt. Vorteil: Keine Parameterübergabe. Jetzt laufen also in zwei unabhängigen Fenstern die Animationen ohne sich gegenseitig zu beeinflussen. Wenn ich jetzt die Bildmatrix lade, bleibt naturalmente auch weiterhin die Diashow hängen aber ich kann ja das Anzeigefenster per die Bildanimation solange in den Hinergrund schieben. Damit zeigt nun das erst Fenster meine Laufschriften und ein Logo. Sobald alles geladen ist, hole ich das zweite Fenster wieder in den Vordergrund. Und voilà! Es sieht aus wie gewollt. jetzt kann ich mich in Ruhe bis September um meine Anzeigeanimationen kümmern. Ich gebe zu das es jetzt nicht die Feine Art ist aber es corre. Erstmal Danke per deine Aiuto und Aufmunterung.
Habe mir Deine Animationen mal angesehen - echt klasse! |
|
|
| |
|
|