Je viens de Dear ImGui

Dear ImGui reconstruit son interface à chaque image à partir d'appels, ce qui est le même instinct qu'ici. Deux choses diffèrent : keal-view décrit un arbre puis le met en page, au lieu d'émettre de la géométrie au fil de l'eau ; et il ne tourne pas à la cadence d'un jeu — il dort jusqu'à ce qu'il se passe quelque chose.

Dear ImGuikeal-view
ImGui::Text("Hi")label("Salut")
if (ImGui::Button("Go")) { … }button("Go", { -> … })
ImGui::SliderFloat(&v, …)slider(v, { x -> … })
ImGui::SameLine()row([…])
ImGui::PushStyleColorle thème, lu par tout
ImDrawListcustom({ p -> p.canvas… })
DockBuilderDock, leaf et split

Ce qui va vous surprendre

Un gestionnaire s'exécute quand le clic a lieu, pas à l'image suivante

En mode immédiat, un bouton rapporte le clic de l'image précédente comme valeur de retour de celle-ci. Ici l'arbre est construit, mis en page, puis on lui remet les événements, donc un gestionnaire s'exécute contre la mise en page sur laquelle l'utilisateur a réellement cliqué — y compris sur l'image où la fenêtre a changé de taille.

Il n'y a pas de GPU, et c'est le propos

Dear ImGui produit des tampons de sommets pour un moteur de rendu que vous fournissez. keal-view remplit un tampon de pixels 0xAARRGGBB sur le processeur et le remet à la fenêtre. L'anti-crénelage est analytique plutôt que multi-échantillonné, donc une courbe coûte ce que coûte son bord et il n'y a pas de réglage de qualité.

L'état survit à l'image sans que vous le teniez

ImGui garde son état interne rangé par une pile d'identifiants sur laquelle il faut raisonner. Ici le même problème est résolu de la même manière — l'identité — mais l'identité est la position d'un nœud dans l'arbre, et .keyed("…") est la façon de dire que la position est la mauvaise réponse.

← Toutes les boîtes à outils