ZFX + Developia

Chromanoid hat geschrieben:Zu IMGUI: Ich bin eigentlich MVVM Fan. Der IMGUI Weg erscheint mir nicht sehr skalierbar. Wenn man sowas sieht https://github.com/AdrienHerubel/imgui/ ... le_gl3.cpp juckt es doch in den Fingern, die Aufrufe in eigene Objekte zu packen. Die Parameter der Methoden werden zu Eigenschaften, man lädt die Objekte dann aus einer Datei und man möchte nur noch das Verhalten in der Anwendung beschreiben. *Zack* man ist wieder kurz davor Events zu verwenden... Vielleicht wäre ein Weg das ganze trotzdem direkt zu steuern, statt Events einfach aus der Liste die relevanten Elemente herauszusuchen und das besondere Verhalten pro Durchlauf per Methoden-Pointer einzufügen.

Schrompf hat geschrieben:Ich mache mir allerdings Sorgen, ob man da auch die ganzen Produktivitätsmerkmale aktueller GUIs unterbekommt.

Schrompf hat geschrieben:Ein Controller dagegen gibt mit seinem eigenen State nur die erste Ableitung an. Wer aber berechnet daraus den neuen Zustand, also welches Widget als nächstes fokussiert ist, wenn der Button beim Zeichnen noch nicht weiß, welche Controls nach ihm noch kommen?

CodingCat hat geschrieben:

Chromanoid hat geschrieben:Wenn man sowas sieht https://github.com/AdrienHerubel/imgui/ ... le_gl3.cpp juckt es doch in den Fingern, die Aufrufe in eigene Objekte zu packen. Die Parameter der Methoden werden zu Eigenschaften, man lädt die Objekte dann aus einer Datei und man möchte nur noch das Verhalten in der Anwendung beschreiben. *Zack* man ist wieder kurz davor Events zu verwenden...

Ich kann mich nicht an Einzelheiten des Artikels erinnern (ich glaube gar, ich habe nur den Titel gelesen und Code überflogen), aber aus meiner Sicht verfehlst du den Punkt

dot hat geschrieben:Entweder, ich berechne in jedem Frame das komplette Layout ständig neu

dot hat geschrieben:Ein extrem wichtiger Spezialfall von Layout versteckt sich hinter Text Rendering. Text Layout ist extrem komplex (Unicode auf und ab, Spacing, Kerning, Justification, Text Directionality ...). Anzunehmen, dass man eben mal drawString("hello world!") macht und gut ist, ist nett, ab einem gewissen Punkt aber leider auch einfach nur noch realitätsfremd.

dot hat geschrieben:Standardinteraktionen mit dem User wie z.B. Resizen von Controls müssten wohl durchgehend selbst implementiert werden, es kann ja nichtmal sowas wie z.B. das Konzept eines Inputfokus geben.

dot hat geschrieben:Außerdem will ich nicht in jedem Frame für alle 223 Buttons testen müssen, ob der Mauszeiger im Button liegt oder nicht, wenn gerade mal 3 davon auch nur in der Nähe wären. Klar, natürlich kann man auch hier eine bessere Lösung dem User überlassen. Langsam stellt sich dann aber unweigerlich die Frage, inwiefern sowas nützlich ist und sich "GUI Library" nennen darf, wenn alle möglichen Dinge, die eigentlich Implementierungsdetails sein sollten, dem User nicht nur überlassen, sondern für den User schon überhaupt auch nur sichtbar werden.

dot hat geschrieben:Auch im Hinblick auf Energieeffizienz möge so ein Ansatz in einem Spiel vielleicht gerade noch vertretbar sein, in einer normalen Anwendung ist es imo aber ein absolutes No-Go, die ganze GUI ständig neu zu rendern.

dot hat geschrieben:Ich hab auch schon länger drüber nachgedacht; ich denke, dass GUI vermutlich einfach von Natur aus untrennbar mit gewissem State verbunden ist, weswegen es eine völlig zustandslose Lösung rein prinzipiell gar nicht geben kann. State duplication allerdings, lässt sich wohl vermeiden. Ich denk im Moment über einen Ansatz nach, der rein presentation-spezifischen Zustand in einer retained mode Struktur hält, sich content-spezifischen Zustand wie z.B. den Text auf einem Label aber, wann immer benötigt, per Callback vom User holt. Genau in dieser Unterscheidung zwischen Presentation und Content liegt imo der eigentliche Knackpunkt; obige immediate mode Lösung setzt implizit gewissermaßen ja ebenfalls genau dort an...

CodingCat hat geschrieben:

dot hat geschrieben:Entweder, ich berechne in jedem Frame das komplette Layout ständig neu

Ja, genau das tue ich in meinem Prototyp, und genau das erachte ich im Kontext von Content Creation Tools als gangbar und sinnvoll ...

CodingCat hat geschrieben:

dot hat geschrieben:Ein extrem wichtiger Spezialfall von Layout versteckt sich hinter Text Rendering. Text Layout ist extrem komplex (Unicode auf und ab, Spacing, Kerning, Justification, Text Directionality ...). Anzunehmen, dass man eben mal drawString("hello world!") macht und gut ist, ist nett, ab einem gewissen Punkt aber leider auch einfach nur noch realitätsfremd.

... nein, im Allgemeinen ist das eigentlich nicht realitätsfremd, es sei denn du entwickelst einen WYSIWYG Text-Editor. Einfaches Alignment an festen Grenzen ist kein Problem, Kerning lässt sich genau wie Glyphzuordnung seitens UI-Bibliothek in entsprechenden Datenstrukturen sehr schnell nachschlagen, wenn notwendig kannst du auch noch problemlos eine UTF-8-Dekodierung voranstellen.

CodingCat hat geschrieben:

dot hat geschrieben:Standardinteraktionen mit dem User wie z.B. Resizen von Controls müssten wohl durchgehend selbst implementiert werden, es kann ja nichtmal sowas wie z.B. das Konzept eines Inputfokus geben.

Input-Fokus sowie Mouse Capture habe ich bereits wie oben skizziert implementiert, das ist kein Problem. Persistentes Resize auf Control-granularer Ebene passt tatsächlich schlecht ins zustandslose Konzept, ich sehe aber dafür im von mir angestrebten Zielkontext der Zugänglichmachung und Bearbeitung großer Datenbäume auch keine Notwendigkeit. Mittelfristiger Zustand während der Bearbeitung einer konkreten Untermenge der Daten ist hingegen kein Problem, analog zu Input-Fokus lässt sich auch gepufferte Text-Eingabe, Resize etc. für gerade aktive Controls implementieren.

CodingCat hat geschrieben:

dot hat geschrieben:Außerdem will ich nicht in jedem Frame für alle 223 Buttons testen müssen, ob der Mauszeiger im Button liegt oder nicht, wenn gerade mal 3 davon auch nur in der Nähe wären. Klar, natürlich kann man auch hier eine bessere Lösung dem User überlassen. Langsam stellt sich dann aber unweigerlich die Frage, inwiefern sowas nützlich ist und sich "GUI Library" nennen darf, wenn alle möglichen Dinge, die eigentlich Implementierungsdetails sein sollten, dem User nicht nur überlassen, sondern für den User schon überhaupt auch nur sichtbar werden.

Culling/Tree Pruning ist bei großen Datenmengen definitiv ein Muss, aber genau Aufgabe der UI-Bibliothek und nicht des Benutzers. Auch dies lässt sich über versteckten Zustand und eindeutige Control-Pfad-Identifier lösen - der Trick ist abermals, den Zustand ohne Rückabhängigkeiten zu den Daten zu speichern, um in nachfolgenden Frames fehlende/neue Teile im Rahmen des Aufbaus der UI erkennen zu können, ohne dass Benachrichtigung/Synchronisation seitens der Daten erforderlich wird.

CodingCat hat geschrieben:

dot hat geschrieben:Auch im Hinblick auf Energieeffizienz möge so ein Ansatz in einem Spiel vielleicht gerade noch vertretbar sein, in einer normalen Anwendung ist es imo aber ein absolutes No-Go, die ganze GUI ständig neu zu rendern.

Das ist ein wichtiger Punkt und ich sehe für diese radikale Art von UI tatsächlich nur ein begrenztes Einsatzgebiet, dort spart es aber meines Erachtens einen riesen Haufen Arbeit verglichen mit unzähligen UI-Bindings bzw. ganzen Ports von Engines in andere Sprachen (C#), wo Frameworks mehr Unterstützung für automatisierte Bindings auf Kosten von Speicher- und Laufzeiteffizienz bieten.

CodingCat hat geschrieben:

dot hat geschrieben:Ich hab auch schon länger drüber nachgedacht; ich denke, dass GUI vermutlich einfach von Natur aus untrennbar mit gewissem State verbunden ist, weswegen es eine völlig zustandslose Lösung rein prinzipiell gar nicht geben kann. State duplication allerdings, lässt sich wohl vermeiden. Ich denk im Moment über einen Ansatz nach, der rein presentation-spezifischen Zustand in einer retained mode Struktur hält, sich content-spezifischen Zustand wie z.B. den Text auf einem Label aber, wann immer benötigt, per Callback vom User holt. Genau in dieser Unterscheidung zwischen Presentation und Content liegt imo der eigentliche Knackpunkt; obige immediate mode Lösung setzt implizit gewissermaßen ja ebenfalls genau dort an...

Soweit ich weiß arbeiten einige Frameworks (Android?) bereits genau so. Das eigentliche Problem von nicht-Immediate UIs bleibt aber bestehen: Sobald nicht konsequent die ganze Zeit Updates durchgeführt werden, brauchst du Benachrichtigung über Veränderung bzw. Invalidierung von Teilbereichen deiner UI. Deshalb funktioniert das IMGUI-Konzept überhaupt nur in dieser radikalen Form.

dot hat geschrieben:Natürlich, bis zu einem gewissen Grad kann man alles machen. Aber es ist imo einfach dermaßen verschwenderisch, dass ich nichtmehr ruhig schlafen könnte, wenn ich wüsste, dass mein UI tatsächlich in jedem Frame rekursiv das komplette two-pass Layout durchrechnet und jeden einzelnen Buchstaben neu platziert... ;)

dot hat geschrieben:Naja, dieser Trick funktioniert wohl in der Praxis ganz gut, ich empfinde ihn aber als ein wenig unsauber. Egal ob man jetzt Pointer oder sonst irgendwelche IDs verwendet. Wenn ich einen Button lösche und gleich drauf einen neuen mach, hab ich zumindest bei Pointern das Problem, dass mein neuer Button potentiell die selbe Adresse hat und das GUI niemals mitbekommt, dass das jetzt plötzlich ein anderer Button ist. Insbesondere bei generierten IDs kann man dies zwar bis zu einem gewissen Grad beeinflussen, aber es ist irgendwie dennoch ein Hack um ein prinzipielles Problem eher auszugleichen als zu lösen. Auch brauch ich natürlich wieder einen weiteren Lookup und mein User muss für jedes Control nun auf einmal eine ID bereitstellen... ;)

dot hat geschrieben:Ich sage ja nicht, dass ich die Vorteile des immediate mode Ansatzes nicht sehe. Leider ist er aber wohl doch eher recht ineffizient und funktioniert überhaupt nur unter sehr speziellen Voraussetzungen, die viele Dinge, die man von einem modernen UI erwarten würde, von vornherein ausschließen oder nur in beschränktem Umfang erlauben. Die meisten UI Toolkits sind in der Tat furchtbar, Events ein direkter Pfad in die Hölle, ich wünschte, es gäbe bessere Lösungen...

CodingCat hat geschrieben:

dot hat geschrieben:Natürlich, bis zu einem gewissen Grad kann man alles machen. Aber es ist imo einfach dermaßen verschwenderisch, dass ich nichtmehr ruhig schlafen könnte, wenn ich wüsste, dass mein UI tatsächlich in jedem Frame rekursiv das komplette two-pass Layout durchrechnet und jeden einzelnen Buchstaben neu platziert... ;)

Genau hier sehe ich aber in einer Anwendung, die jedes Frame mehrere Millionen Dreiecke rendert, nicht das Problem. :P

The good..
● No object creation
● No cleanup either
● No queries for information
● No message passing
● Data owned by application, not the widget
● Everything is “immediate” - one call per widget, each frame, handles behavior and rendering.

..the bad..
● Requires different kind of thinking
● Wastes CPU time
– But in games you're re-rendering stuff 50+ fps anyway..
● UI generated from code; No designer-friendly tools.
– Unless you make some...

..and the ugly.
● While making easy things dead easy, makes complicated things very complicated.
– The UI system internals may become even more complex than in “traditional” GUI library!
● UI logic interleaved to rendering
– Can be overcome by more complex internals.
● Pretty “anti-OOP” (although this is debatable)
● Not a silver bullet.

Für andere Dinge sollte HTML5 immer interessanter werden

//anstatt
//1.Frame
Label = new Label(xpos, ypos, width,height,"Hello");
//2.Frame
label.setText("Hello2"); //greift auf den Zustand zu, ist meist wesentlich komplexer

//machen wir
//1. Frame
gui.clear();
gui.CreateLabel(xpos,ypos, width,height,"Hello");
gui.render();
//2. Frame
gui.clear();
gui.CreateLabel(xpos,ypos, width,height,"Hello2");
gui.render();

//Ausgabe bei aufruf der index.html
echo("<b class="label">Hello</b>");
//Ausgabe nach POST
echo("<b class="label">Hello2</b>");

gui.CreateButton(xpos,ypos, width,height,gui.CreateLabel("Yeah"));
//erzeugt dann sowas wie:
//<p class="button"><b class="label">Yeah</b></p>