hier nochmal mein beitrag aber diesmal im richtigen forum:

Hallo,
viel zeit ist vergangen seit mir klar wurde, ein HUd reicht nicht, du brauchst eine GUI.
Also hab ich angefangen zu basteln und zu programmieren, alles läuft super, ich hab einen Editor erstellt mit dem ich ein Fenster live erstellen kann.

Nur macht wiedermal TextSuite probleme.

als erstes mal kurz zur funktionsweise meines editors,

es ist eigentlich ganz einfach mit jedem frame werden aus einem "TValueListEditor" alle informationen des Fensters gelesen, mit hilfe von sehr vielen abfragen wird nun aus einem Monströsen block renderprocedure genau das ausgeführt damit das Fenster rauskommt welches der User sich vorgestellt hat.

ist der user zufrieden geht man auf einen exportirenbutton und mithilfe von wiederum sehr vielen abfragen wird ein Code erstellt und sortiert der dann genau das Fenster ausgiebt welches zuvor erstellt wurde.


um die schriftgröße zu verändern wird die schrift in jedem frame neu erstellt, das ist an sich kein problem, nur gibt es ein paar stellen wo Fehler auftreten die eigentlich nicht auftreten dürften.

1. wenn eine Textur auf oder hinter das Fenster gelegt werden soll öffnet sich der "OpenDialog", man wählt die textur aus sie wird geladen und dann gibt TextSuite einen error das die schriftart-datei nicht geöffnet werden könne,

das ist aber auch eigentlich gar nicht notwendig da ich ja nicht den Contex der schriftarten neu erstelle sondern nur die schriftart an sich.

2. ich rendere zuerst das grundfeld des fensters dann die menüleiste, die aufschrift der leiste und als letztes den Kleinen button mit dem X, mein problem ist aber das die farbe die ich dem Schließen-kästchen zuordne fast vollständig ignoriert wird, es ist mal schwarz mal weiß mal grau mal in der farbe die ich ausgewählt habe, das ganze ergibt ein sehr unschönes flackern.

durch probieren konnte ich feststellen das der befehl "tsTextOutA(PChar(Window.Caption));" dafür verantwortlich ist.


weiß jemand wie man diese beiden fehler (die übrigens die einzigen sind von denen ich bisher weiß) ausmerzen könnte? ich kann auch codebeispiele reinstellen und/oder mehr info´s bereitstellen wenn dies weiterhilft.


lg André

Ich hab Lossy mal angeschrieben. Er wird sicherlich, sobald er Zeit hat, dir sagen können was nicht stimmt.

Alternativ gibt es einige Leute hier, die auch GUIs und GUI Editoren bereits geschrieben haben. Die können dir vielleicht auch ein paar Tips geben, wie man die Sache angehen kann.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

1. Also das darfst du nicht machen. Der Kontext an sich dient nur zur Gruppierung der Objekte und Einstellungen. Er ist in der TextSuite eher ein Leichtgewicht. Die Hauptarbeit geschieht innerhalb der Fontobjekte. Wird eines dieser Objekte erstellt, dann muss die API (Winapi oder SDL) angewiesen werden die Fontdatei zu laden. Obendrein wird beim Löschen eines Fonts dessen Texturspeicher aufgeräumt. Im schlimmsten Fall kannst du glück haben, dass in jedem Frame eine Textur erstellt und wieder gelöscht wird. Oben drauf kommt noch, dass in jedem Frame alle Buchstaben immer wieder neu erstellt werden müssen. Das Rendern der Fonts dauert. Nachbearbeitung dauert. Und das Übertragen dauert auch. Und Caching über Framegrenzen hinweg wird so komplett verhindert. Da solltest du in jedem Fall eine andere Lösung für finden!

Dein eigentliches Problem. Benutzt du relative Pfade beim Erstellen der Fonts? Ich behaupte mal ja. Wenn du einen Öffnen/Speichern Dialog öffnest, dann wird der aktuelle Pfad für die Anwendung verschoben. Entsprechend kann er die Dateien nicht mehr finden. Das aktuelle Verzeichniss ist zu Begin einer Anwendung auf das Verzeichniss einer Anwendung gesetzt. Sofern das in Windows (Verknüpfungen) nicht anderes angegeben wurde (Ausführen in). Das Problem hast du überall wo mit Dateien und relativen Pfaden gearbeitet wird. Da kann ich dir nur empfehlen vollständige Pfadangaben zu verwenden. Zu begin deiner Anwendung "AppDir := ExtractFilePath(ParamStr(0))" und dann "AppDir + 'Fonts\Font.blah'". Überprüfe aber mal ob ExtractFilePath auch ein Backslash anhängt. Bin mir nicht sicher.

2. Wie zeichnest du denn die Schließen Schaltfläche? Vermutlich nicht über eine Textur. Die TextSuite benutzt Texturen um die Buchstaben zu zeichnen. Wenn du fertig bist mit Text ausgeben, dann musst du selbst glBindTexture(GL_TEXTURE_2D, 0) oder glDisable(GL_TEXTURE_2D) aufrufen. Dann wird die Texture entbunden. Ansonsten wird die auf alle nachfolgende Objekte übertragen. Die TextSuite kann das nicht machen, da ich nicht weiß wann du fertig bist. Und das nach jedem Aufruf zu machen würde zu viel Leistung kosten.

also das mit dem schließen button, da hätte man eig auch allein darauf kommen können :/

und bei der schriftart danke ich dir vielmahls für diese erklärung, der wert für die schriftgröße wird nun jedes mal gespeichert und mit dem vorhergehenden wert verglichen hat er sich verändert wird die schriftart neu erstellt

aber ich hab gleich noch eine weitere frage, das ist mir eben beim rumspielen aufgefallen

jeder prozess hat doch einen zugesicherten arbeitspeicher den man im Taskmanager nachschauen kann, bei allen prozessen bleibt dieser meist konstant oder verändert sich nicht ausschlaggebend
bei meinem prozess sieht das nicht anders aus, solang ich keine Texturen verwende

wenn ich eine Textur verwende steigt der genutzte speicher stetig und proportional zur zeit an.

ich hab es getestet das ganze steigt solange bis ich einen error bekomme weil nicht mehr genug speicher da ist um das fenster darzustellen. Muss ich irgendetwas beachten damit das nicht passiert? ich hab eigentlich alles sowie immer und bei meinen anderen programmen ist das auch nicht der fall das dass so ansteigt

Das klingt sehr stark nach einem Speicherloch. Also, dass du vergisst etwas freizugeben oder es fälschlich am laufenden Band immer neu erstellst.

Du kannst dir auch mal FastMM installieren. Unit in deiner dpr als erstes einbinden und dann in der IDE starten. Kurz laufen lassen, beenden und dann schauen was er dir anmeckert. Normal sollte da auch eine Logdatei erstellt werden. Dort stehen dann noch mal zu jedem Leck etwas mehr Informationen.

ok, ich hab das gemacht, super sache muss ich sagen wenn man damit arbeiten kann erspart das sicher viel suchen

das ergebniss sieht nun so aus



ich versuch gerade noch irgendwie das log zu aktivieren aber ich weiß noch nicht so recht wie, aber ich bekomm das hin keine angst^^

@Dropeye

wenn du die Memory Leaks wegbekommen hast, kannst dann kurz hier posten was da so war? Weil ich habe den Thread hier verfolgt und auch mal das FastMM gezogen, bei mir sieht es sehr ähnlich aus, wie bei dir:

ok ich habs, logging is aktiv

aber was zum henker is das oO



davon hab ich einige blocks in einer datei namens: GUIEditor_FastMM_Log.txt(37,4MB nach einem aufruf)

die blocks sind alle unterschiedlich, ich hab nur den mal genommen um ein beispiel zu geben

Also die Speichermenge ist recht lächerlich. 19k sorgt nicht für einen kontinuierlichen Anstieg des Speichers.

Die Objekte sind mit Tts sind allerdings von der TextSuite. Da behaupte ich einfach mal. tsQuit vergessen? Wenn tsQuit nicht aufgerufen wird, dann bleibt der Kontext + ein paar andere Objekte über. tsQuit sollte hoffentlich alles freiräumen was irgendwie noch rumschimmelt und direkt zur TextSuite gehört.

Was FastMM nicht berücksichtigen kann sind Speicher die über OpenGL erstellt werden. Also Texturen VBOs etc. Dadurch kann es auch passieren, dass die Anwendung laut TaskManager mehr Speicher frisst sie es normal tut. Speziell bei Karten mit Sharedmemory liegt das alles immer im RAM. Eine leere Anwendung frisst so locker auch mal 80 MB+. Und alles was im Treiber läuft geht natürlich auch zu lasten deiner Anwendung.

daran hat ich ja gar nich gedacht, jetzt gibt FastMM schonmal ruhe

@ wölfchen

einfach alles am ende schön freigeben und auf nil sezten dann gibt FastMM ruhe


aber das eigentlich problem hatt sich damit noch nicht geklärt, ich habs nochmal gescreent und hoff das es so deutlicher wird



der speicherverbrauch steigt ins unermessliche biss das programm den kompletten arbeitspeicher einnimmt bzw vorher abstürzt

Ja Danke!

ein im form close Ereignis hat FastMM zum Schweigen gebracht.

Ich bin derzeit einem anderen Speicherplatzproblem auf der Spur, werde aber einen eigenen Thread aufmachen wenn ich weiß, was Masse ist.

Das bei dir sieht seltsam aus... so als würdest du bei jedem reframe was dazuladen...

Also wenn FastMM jetzt nichts mehr zu meckern hat dann muss es irgendwas in OpenGL sein. Da solltest du dann mal überprüfen ob du alles Texturen oder sonstigen OpenGL Objekte auch wieder wegräumst und nicht bei jedem Frame ein Neues erstellst.

ich habs gefunden,

es ist die textur des Fensters welche ich fälchlicher weise immer wieder in jedem Frame neu geladen habe

ich habe das abgeändert und nun bleibt der speicherplatz stabiel

danke für eure hilfe