Interaktion, Rendering und Zustand

Bei interaktiver Software liegt die eigentliche Arbeit nicht bei Farben, Abständen oder Widget-Namen. Die harten Probleme beginnen dort, wo ein System gleichzeitig Geometrie zeichnen, Eingaben auswerten, Zustände halten, Text editieren, Auswahl sichtbar machen und Änderungen wieder zurücknehmen muss. Genau dort trennt sich eine bloße Oberfläche von einem Werkzeug.

nkrunner arbeitet in diesem Bereich. Der Kern liegt nicht in einem Satz fertiger Controls, sondern in den technischen Schichten darunter: Objektmodell, Eingabeverarbeitung, Picking, Text, Shader, Pipeline-Zustände, Historie und Nebenläufigkeit. Diese Dinge greifen direkt ineinander. Sobald eine dieser Schichten unsauber wird, zerfällt das Verhalten an der Oberfläche.

Objektmodell und Eingabefluss

Ein Objekt in so einem System ist nicht nur Geometrie. Es braucht Identität, Auswahlzustand, Editierbarkeit und eine klare Beziehung zu Eingaben. Maus und Tastatur dürfen nicht als lokale Sonderfälle wachsen. Hover, Selektion, Mehrfachselektion, Fokus, Editiermodus und Tastaturkommandos brauchen gemeinsame Regeln. Sonst entsteht kein Interaktionskern, sondern eine Sammlung zufälliger Verzweigungen.

Das betrifft auch die Historie. Undo und Redo sind nicht Beiwerk. Sie zwingen dazu, Zustandsänderungen explizit zu machen. Ohne diese Disziplin wird jede spätere Erweiterung teurer, weil das System intern nicht mehr sauber sagen kann, was sich wann geändert hat.

Picking als eigener Pfad

nkrunner behandelt Picking nicht als Nebenprodukt des sichtbaren Bildes. Dafür gibt es einen eigenen Offscreen-Pass mit separatem Farb- und Depth-Attachment. In diesen Pass wird nicht „schön“ gezeichnet, sondern eindeutig. Jedes Objekt bekommt eine Picking-Farbe. Der Mauszeiger liest anschließend genau ein Pixel aus diesem Buffer zurück. Daraus entsteht die Objekt-ID, und erst danach wird entschieden, ob ein Resize-Handle, ein Fenster oder ein anderes Objekt getroffen wurde.

Das ist der richtige Ort für Picking. Sichtbare Geometrie und auswertbare Geometrie sind zwei verschiedene Probleme. Ein dünnes Element kann optisch korrekt sein und trotzdem schlecht treffbar. Ein eigener Picking-Pfad erlaubt andere Regeln als der sichtbare Renderpfad. Genau deshalb gibt es im Projekt auch zusätzliche Fangflächen, etwa für kleine HUD-Elemente oder Textbereiche. Bedienung hängt daran, dass Dinge zuverlässig adressierbar bleiben, nicht daran, dass sie nur korrekt aussehen.

Shader und Shader-Compiler

Der Shader-Pfad ist ebenfalls klar getrennt. Ein Hauptshader verarbeitet Position, Normalen und Farbe und berechnet daraus Weltposition, transformierte Normale und Fragmentfarbe. Im Fragmentpfad gibt es mehrere Modi: beleuchtete 3D-Ausgabe, unbeleuchtete Solid-Farben für Rahmen und ein reiner Linienmodus. Das ist sauberer als ad hoc verteilte Spezialshader für jeden Einzelfall.

Für 3D-Geometrie wird im Shader nicht nur flach Farbe ausgegeben. Es laufen Ambient-, Diffuse- und Specular-Anteile zusammen. Die Kameraposition geht als Uniform ein, damit Glanzlichter aus der Blickrichtung berechnet werden können. Das ist kein Gimmick, sondern Teil eines konsistenten Material- und Sichtbarkeitsmodells.

Der Shadercode bleibt dabei nicht an ein einzelnes Backend gebunden. Er wird mit sokol-shdc in backend-spezifische Beschreibungen übersetzt. Statt denselben Pfad mehrfach per Hand für verschiedene Grafik-Backends zu pflegen, gibt es einen zentralen Shader-Eingang und daraus erzeugte Backend-Artefakte.

Wichtig ist dabei die genaue Einordnung:

• Die Hostsprache des Projekts ist Nim.
• Die primäre Shader-Quellsprache im Projekt ist GLSL.
• Genauer gesagt wird eine von sokol-shdc erwartete Form von annotated GLSL bzw. Vulkan-style GLSL verwendet.
• Metal, HLSL und WGSL werden im Projekt nicht als primäre Shaderquellen von Hand geschrieben.
• Stattdessen wird ein zentraler GLSL-Shader gepflegt, aus dem die backend-spezifischen Beschreibungen erzeugt werden.
• Daraus entstehen Bindings, Attribut-Layouts, Uniform-Blöcke und Shader-Deskriptoren für GLSL, Metal, HLSL und WGSL.
• Der eigentliche Vorteil liegt nicht nur in Bequemlichkeit, sondern in Konsistenz: Vertex-Layout, Uniform-Schnittstellen und Shader-Metadaten werden nicht backendweise auseinandergezogen.
• Dadurch sinkt die Gefahr, dass ein Shader auf einem Backend bereits angepasst wurde, auf einem anderen aber noch mit veralteten Bindings oder Layout-Annahmen läuft.
• Die Sprache des Projekts für Shader ist also nicht „Nim-Shader“, sondern weiterhin GLSL; Nim steuert nur die Hostseite, also Pipelines, Ressourcen, Draw-Aufrufe und Zustandsverwaltung.
• sokol-shdc ist in diesem Zusammenhang der Übersetzungs- und Ableitungspfad zwischen der einen gepflegten Shaderquelle und den verschiedenen Ziel-Backends.

Gerade diese Trennung ist architektonisch sauber. Nim beschreibt die Programmlogik auf CPU-Seite. Der Shader bleibt ein Shader. Und die Backend-Anpassung wird nicht als verstreute Handarbeit über das Projekt verteilt, sondern in einen klaren Compilerpfad verlagert.

Pipelines statt impliziter Zustände

Ein erheblicher Teil der Architektur steckt in den Pipeline-Beschreibungen. Primitive-Typ, Sample-Count, Depth-Test, Blendzustand, Vertex-Layout und Cull-Mode werden pro Pfad explizit gesetzt. Das ist nicht dekorativ, sondern zwingend. Linien, Dreiecke, Picking, HUD-Quads, transparente Überlagerungen und Fullscreen-Ausgabe haben unterschiedliche Anforderungen. Wer das in lose Zustandsschalter zerlegt, verliert schnell die Kontrolle.

Im Projekt ist das bereits sichtbar. Es gibt getrennte Pipelines für Linien, Dreiecke, Picking, Lasso, HUD-Picking, Fullscreen-Quad und Text. Dazu kommen unterschiedliche Sample-Counts und verschiedene Depth- und Blend-Regeln. Eine Linie läuft anders als ein gefülltes Objekt. Ein Picking-Pass läuft anders als die sichtbare Szene. Ein Text-Pass mit Alphablending stellt andere Anforderungen als ein opaker Körper im Raum.

Diese Trennung ist keine akademische Reinheit. Sie reduziert Kopplung. Eine Pipeline beschreibt, unter welchen Bedingungen ein bestimmter Pfad gültig ist. Dadurch bleibt sichtbar, was eine Renderstufe wirklich erwartet.

Stencil für Hover und Selektion

Hover- und Selektionsrahmen werden nicht als lockere Übermalung behandelt. Dafür werden Stencil-Zustände benutzt. Zuerst markiert eine Pipeline die Fläche des Objekts im Stencil-Buffer. Danach zeichnet eine zweite Pipeline nur dort, wo der Stencil-Test nicht mehr auf die ursprüngliche Fläche trifft. So entsteht eine Outline, die geometrisch vom Objekt getrennt bleibt.

Das ist die saubere Lösung für stabile Rahmen. Eine bloß über das Objekt gelegte zweite Fläche kippt schnell in Tiefenprobleme, Überdeckungen oder unscharfe Hervorhebungen. Ein Stencil-basierter Pfad bleibt präziser. Im Projekt werden dafür unterschiedliche Referenzwerte für Hover und Selektion verwendet. Damit können beide Zustände technisch getrennt behandelt werden, obwohl sie im selben Bildraum liegen.

Text als Belastungstest

Text ist fast immer der Punkt, an dem eine UI-Architektur ihre Schwächen offenlegt. nkrunner geht diesen Teil nicht als Bitmap-Text an, sondern mit SDF-Text. Der Font-Atlas wird aus JSON-Metriken und Textur geladen. Der Textshader liest die Distanzwerte aus dem Atlas und berechnet die Kanten im Fragmentshader mit fwidth und smoothstep. Das ergibt skalierbaren Text ohne sofortige Treppenkanten.

Wichtiger als die Technik des Font-Atlas ist aber, was daran hängt: Cursorgeometrie, Blinklogik, Navigation, Einfügen, Löschen, Scrollen und sichtbare Rückmeldung. An Text wird schnell klar, ob Eingaben, Layout und Darstellung wirklich zusammenspielen. Ein Projekt, das Text nur anzeigt, ist an dieser Stelle noch harmlos. Ein Projekt, das Text editiert, muss intern deutlich sauberer werden.

Nebenläufigkeit

Auch Threading taucht im Projekt nicht nur als Theorie auf. Es gibt einen klassischen Analyse-Thread mit Lock-Schutz für gemeinsame Meldungsdaten, und daneben einen separaten Worker mit atomarem Integer-Zustand. Das ist noch kein großer Scheduler und kein ausgebautes Jobsystem. Es zeigt aber die richtige Trennlinie: Hintergrundarbeit darf den UI-Takt nicht blockieren.

Das ist für Werkzeuge wichtiger als für bloße Viewer. Sobald Dateianalyse, Auswertung oder spätere Berechnungen neben Eingaben laufen, muss der Hauptthread frei bleiben. Sonst beginnt die Oberfläche zu stottern, obwohl die Algorithmen für sich genommen korrekt sind. Reaktionsfähigkeit hängt daher nicht nur an Zeichenroutinen, sondern auch an der Art, wie Zustände zwischen Threads übergeben werden.

Einordnung

Figma arbeitet auf der Ebene des Entwurfs. Dort geht es um Komponenten, Layout, Varianten und Übergabe. Das ist ein anderes Problemfeld. nkrunner liegt tiefer. Hier geht es nicht um die Beschreibung einer Oberfläche, sondern um deren Ausführung als System: Objektidentität, Picking, Text, Pipeline-Zustände, Shader, Historie und Eingabefluss.

Auch im Nim-Umfeld ist das keine triviale Nische. Deklarative Oberfläche, Web-Denken oder Design-Überführung sind eigene Richtungen. nkrunner zielt auf den technischen Kern eines laufenden Werkzeugs. Dieser Kern ist langsamer aufzubauen als ein Satz sichtbarer Screens. Er ist dafür architektonisch ergiebiger.

Schluss

nkrunner ist damit keine Sammlung netter Einzeltricks. Der Wert liegt in der Kopplung der richtigen Probleme: Picking nicht im sichtbaren Bild, sondern im eigenen Pass. Hover und Selektion nicht als Farbklecks, sondern über Stencil-Zustände. Text nicht als Sprite-Haufen, sondern über SDF und echte Eingabelogik. Shader nicht backendweise von Hand, sondern über einen Compilerpfad. Hintergrundarbeit nicht im UI-Takt, sondern getrennt.

Wer diese Probleme einzeln löst, bekommt einzelne Features. Wer sie in eine gemeinsame Struktur zwingt, baut eine Grundlage. Genau dort wird entschieden, ob aus einer Oberfläche ein Werkzeug wird.