Generelle Diskussion zu SFGUI

Die grundlegende Idee hinter SFGUI ist ja eigentlich fantastisch: eine moderne und schlanke GUI-Bibliothek, die direkt auf und mit SFML arbeitet.
Was mir jedoch ganz und gar nicht gefällt (und darüber möchte ich gerne diskutieren, wenn jemand Lösungen kennt, wäre das hervorragend) sind die folgenden Punkte:

Ein minimales Programm, kompiliert mit Release-Setting, benötigt konstant gut 100MB RAM: https://i.imgur.com/4NEUMar.png
Eine minimale Loop mit pollEvent , HandleEvent , Update und draw / display mit aktivem V-Sync frisst mir einen Kern, resp. einen Thread komplett weg (siehe Bild von oben).
HandleEvent ist komplett broken und die Devs sehen es entweder nicht ein oder wollen nichts dagegen machen. Zwei Beispiele:
Wenn der Programmierer wissen will, ob sein Mausklick-Event von dem UI registriert und abgehandelt worden ist, was ein ziemlich nützliches und grundlegendes Feature ist, so muss er schon zu extrem hässlichen Hacks greifen: an jedes einzelne Widget einen Listener 'ranhängen und bei einem registrierten Klick ein globales Flag setzen. Richtig hässlich wird die Sache dann, wenn man zur Laufzeit neue Widgets erstellt oder wenn die Software mehrere Threads hat.
Sind ausserdem zwei oder mehrere Widgets hintereinander, was bei verschiebbaren Windows nicht abwegig ist, so wird bei einem Klick OnLeftClick aller Widgets getriggert, auch das derer, die im Hintergrund und u.U. gar nicht sichtbar sind. Hier das korrekte Verhalten zu implementieren wäre extrem simpel, weil es ja schon eine Vorne-Hinten-Hierarchie der Widgets gibt. Man müsste bloss das Event von vorne nach hinten zu handlen versuchen und beim ersten Hit abbrechen. Jede halbwegs dezente GUI-Bibliothek unterstützt diese Funktionalität
Rendering Order stimmt nicht. Obwohl die Child-Widgets alle bei ihren Parents registriert werden müssen und dies ein reibungsloses rekursives Rendern ermöglicht, kommt es dennoch zu inkorrekter Darstellung: https://i.imgur.com/Y9st9Lt.png
Das ist übrigens das Programm, das 100MB frisst und einen 4.0GHz Thread auf 100% bringt.
Font rendering ist buggy, wenn man SFGUI und SFML zusammen verwendet (siehe Bild von oben). Um das zu umgehen, muss man manuell OpenGL-Flags pushen und poppen.

Ich habe mich echt auf SFGUI gefreut, weil es genau das von sich behauptet hatte, was ich eigentlich haben wollte: arbeitet mit SFML, modernes C++, simpel und leicht. Kann man die von mir aufgeführten Probleme irgendwie fixen?
Wenn nicht, was stünden für Alternativen bereit? GTK+ ist in C geschrieben und daher rein funktional, QT ist extrem dick und auf den MOC habe ich erst recht keine Lust. Gibt es eine alternative, sehr leichte GUI-Bibliothek für ein paar einfache Widgets in SFML/OpenGL?

LG

Mechanics

kekster schrieb:

GTK+ ist in C geschrieben und daher rein funktional

gtkmm?

Abgesehen davon benutzen wir Qt und ich seh damit überhaupt kein Problem. "Schlanke" Bibliotheken sind meist kein Kriterium.

Mechanics schrieb:

gtkmm?

Werd' ich mir mal anschauen, danke.

Mechanics schrieb:

Abgesehen davon benutzen wir Qt und ich seh damit überhaupt kein Problem. "Schlanke" Bibliotheken sind meist kein Kriterium.

Ich sehe das anders. Ich will nicht auf jedem meiner Computer die ganze Toolchain herunterladen und kompilieren müssen, nur um mein kleines Programm zu kompilieren. Dazu kommt, dass ich weder die ganzen Makros, noch den MOC wirklich mag. Nicht nur, weil das den Code deutlich hässlicher und nicht standardkonform macht, sondern weil man das auch alles viel eleganter mit Standard-C++ hätte lösen können. Wenn mal ein Qt6 erscheint, das den ganzen Legacy-Code entsorgt (auf Kosten der Rückwärtskompatibilität) und alles, insb. bzgl. Slots/Signals, mit modernem C++11/C++14 löst, dann werde ich mich der Bibliothek mit Freuden nochmals annehmen.

hustbaer

kekster schrieb:

Ein minimales Programm, kompiliert mit Release-Setting, benötigt konstant gut 100MB RAM: https://i.imgur.com/4NEUMar.png

Das ist bei modernen Frameworks leider mehr oder weniger normal.

kekster schrieb:

Eine minimale Loop mit pollEvent , HandleEvent , Update und draw / display mit aktivem V-Sync frisst mir einen Kern, resp. einen Thread komplett weg (siehe Bild von oben).

Da stimmt gröber 'was nicht. Entweder an deinem System (OS, Treiber, ...), deinem Code oder dem Code von SFGUI. Sollte sich auf jeden Fall relativ einfach fixen lassen.

Auch die restlichen Sachen sollte mMn. mehr oder weniger einfach zu beheben sein.

Vielleicht solltest du nochmal mit den Entwicklern reden? Sind das vielleicht Amis oder Briten? Dann könnte leicht sein dass die angepisst waren weil du ihnen zu "unfreundlich" warst (Amis und Briten empfinden manchmal schon einen direkten Hinweis auf ein Fehlverhalten als "flegelhaft", selbst wenn er ganz neutral/sachlich formuliert ist).

Ok, die Probleme mit der Rendering Order und dass Events durch Windows durchgegeben werden konnte ich beheben. War auf mein eigenes Versagen zurückzuführen (und auf die mangelhaften SFGUI-Tutorials), konnte ich aber ausbügeln, nachdem ich mir den Code der mitgelieferten Beispiele angeschaut habe.

hustbaer schrieb:

kekster schrieb:

Eine minimale Loop mit pollEvent , HandleEvent , Update und draw / display mit aktivem V-Sync frisst mir einen Kern, resp. einen Thread komplett weg (siehe Bild von oben).

Da stimmt gröber 'was nicht. Entweder an deinem System (OS, Treiber, ...), deinem Code oder dem Code von SFGUI. Sollte sich auf jeden Fall relativ einfach fixen lassen.

Könnte ich fast nicht glauben, wenn das an 'was anderem als an SFGUI läge. Wenn ich in exakt demselben Code die Zeile mSfGui.Display( Window ); auskommentiere, dann bin ich bei der von SFML gewohnten <1% Prozessorauslastung (dank V-Sync natürlich). Bemerkenswert ist auch, dass ansonsten die meiste Zeit im Kernel Mode vertrödelt wird (dargestellt in rot). Ausserdem lässt sich genau das selbe Verhalten bei allen mitgelieferten SFGUI-Beispielen beobachten.

hustbaer schrieb:

Auch die restlichen Sachen sollte mMn. mehr oder weniger einfach zu beheben sein.

Vielleicht solltest du nochmal mit den Entwicklern reden? Sind das vielleicht Amis oder Briten? Dann könnte leicht sein dass die angepisst waren weil du ihnen zu "unfreundlich" warst (Amis und Briten empfinden manchmal schon einen direkten Hinweis auf ein Fehlverhalten als "flegelhaft", selbst wenn er ganz neutral/sachlich formuliert ist).

Ehrlich gesagt habe ich mich bislang nicht direkt mit den beteiligten Devs in Kontakt gesetzt. Meine Aussage im OP geht zurück auf diesen Forenpost, in dem ein User genau das selbe Verhalten erzielen wollte wie ich. Einer der beiden SFGUI-Devs hat explizit geäussert, dass dieses Verhalten von der Bibliothek nicht unterstützt werden wird. Für mich bleibt es schlicht und einfach ein dreckiger Hack, dass ich an alle Widgets für jedes Event einen Callback dranhängen muss, der mir ein Flag toggled. Ebenso, dass ich vor dem Verarbeiten eines Textevents alle Entry-Widgets durchiterieren muss, um zu schauen, ob irgendeins davon Fokus hat. Aber sei's drum...

hustbaer

Naja das klingt ja schon viel besser.

Was die 100% CPU angeht: Debug es, fix es und schreib den Devs was das Problem ist (bzw. schick' ihnen gleich nen Diff bzw. nen Pull-Request falls du es "sauber" fixen konntest).

Was die gewünschte "OnMouseClickHandled" Funktion angeht kannst du ja auch nochmal selbst nachfragen ob sie das nicht integrieren möchten, weil du es wichtig findest. Bzw. könntest du auch das selbst implementieren und ihnen zur Verfügung stellen. Kann ja mMn. nicht sehr viel Arbeit sein.