Entwickler-Tagebuch

Im Spatial Workspace unserer UI-Engine geht es stetig voran. Nachdem wir in den letzten Tagen die Performance bei tausenden Objekten gesichert haben, lag der Fokus heute auf einem entscheidenden Detail der räumlichen Interaktion: Wie exakt beanspruchen Objekte ihren Platz im Raum und wie verhalten sie sich, wenn sie aufeinandertreffen?

Abb 1: Die neuen Boundaries schließen das eigentliche Frame und die dazugehörige Caption in eine gemeinsame Bounding-Box ein.

Das Problem mit den Beschriftungen

Bisher lag der Fokus der Kollisions- und Layout-Logik primär auf dem eigentlichen Fenster (dem Frame). Das führte in der Praxis allerdings zu visuellen und logischen Unsauberkeiten: Sobald ein Objekt eine Beschriftung (die Objcaption) besaß, die über das visuelle Haupt-Frame hinausragte, wurde dieser Platz vom System nicht vollständig respektiert. Beim Andocken von Fenstern konnte es passieren, dass Frames die Texte benachbarter Objekte überlagerten.

Erweiterte Objekt-Boundaries

Um das zu lösen, haben wir die Berechnung der Bounding-Boxen umgeschrieben. Die neuen Objekt-Boundaries umschließen nun konsequent das gesamte Element: Sie fassen das Haupt-Frame und die Objcaption zu einer gemeinsamen, logischen Einheit zusammen. Die Engine "weiß" nun exakt, wie viel Raum ein Objekt mitsamt seiner Metadaten und Titel wirklich benötigt.

Die neue Grundlage für das Snapping-System

Diese architektonische Anpassung ist weit mehr als nur ein optischer Fix. Die neuen Boundaries bilden ab sofort die exakte mathematische Grundlage für die Snappings zwischen den Frames.

Wenn Nutzer nun Virtual Windows im 3D-Raum verschieben und diese aneinander andocken, greift das Constraint-System auf die erweiterten Bounding-Boxen zurück. Das Andocken passiert exakt an den Außenkanten dieser neuen Geometrie – was zu einer völlig neuen, flüssigen Gruppendynamik führt.

Rasten beispielsweise die drei Masken-Frames aneinander ein, bilden sie fortan einen kohärenten Verbund. Zieht man nun an einem dieser Frames, gleiten die anderen beiden durch die magnetische Bindung nahtlos und synchron mit durch den Raum. Das angrenzende Texteditor-Frame hingegen ist von diesem System bewusst ausgenommen; es bleibt stets ein autarkes, frei platzierbares Element, das sich nicht in diesen Bewegungsfluss einklinkt.

Das Ergebnis ist ein extrem sauberes Layout-Verhalten ohne überlappende Texte. Das visuelle Element der Caption ist endgültig zu einem vollwertigen, berechenbaren Teil der räumlichen Geometrie geworden.

Eine binäre Kooperation ist eine Form arbeitsteiliger Produktentwicklung. Partei A liefert ein kompiliertes Library-Artefakt, Partei B integriert dieses Artefakt in Anwendung, Workflow und UI. Distribuiert wird ein ebenfalls kompiliertes Gesamtprodukt.

Der ökonomische Kern liegt in der Trennung von Benutzbarkeit und Implementierungswissen. Geliefert wird nicht Quelltext, sondern anschlussfähige Funktionalität. Vergütet wird nicht Einsicht in die innere Struktur, sondern die Möglichkeit, ein fremdes Modul kontrolliert in eine eigene Wertschöpfungskette einzubauen.

Teil 1: Die technische Basis – ABI und Opaque Handles

Technisch ist dafür nicht nur eine API relevant, sondern vor allem eine stabile ABI (Application Binary Interface, also die Binärschnittstelle eines bereits kompilierten Moduls). Während eine API die sichtbaren Funktionen und Typen auf Quelltextebene beschreibt, regelt die ABI die tatsächlich relevante Binärverträglichkeit: Aufrufkonventionen, Speicherlayout, Symbolsichtbarkeit, Ownership-Regeln, Fehlertransport und Versionskompatibilität.

Das Opaque-Handle-Pattern ist in diesem Zusammenhang kein Stilmittel, sondern ein Instrument der Kopplungskontrolle. Außen sichtbar ist nur ein undurchsichtiger Handle auf internen Zustand. Außen unsichtbar bleiben Datenlayout, Hilfstypen, Containerwahl und Invarianten. Operationen auf diesem Zustand laufen ausschließlich über exportierte Funktionen. Damit verbleiben Speicherhoheit, Strukturwissen und Refactoring-Freiheit beim Lieferanten.

Das Ergebnis ist eine klare funktionale Aufteilung: Rechenkern auf der einen Seite, UI und Produktkontext auf der anderen. Das begrenzt die technische Angriffsfläche der Kooperation auf eine definierte Binärschnittstelle.

Teil 2: Die offene Plattform – Standards setzen (Open Source)

In der Praxis mündet dieses Architekturmuster fast immer in einem Plugin-System. Es entstehen zwei klare Rollen: Der Host (die Plattform), der Rahmen und Routing stellt, und das Plugin (die Erweiterung), das als dynamische Bibliothek (.so / .dll) exakt die ABI-Schnittstelle bedient.

In der Open-Source-Welt wird der Host oft frei zur Verfügung gestellt, um einen Standard zu etablieren. Bekannte Beispiele finden sich dort, wo klare Schnittstellen auf hochspezialisierte Anforderungen treffen: Der populäre Netzwerkanalysator Wireshark bindet komplexe oder proprietäre Protokoll-Parser (Dissectors) als dynamische .so-Bibliotheken tief in seine Engine ein. Auf dem modernen Linux-Desktop lädt der performante Wayland-Compositor Hyprland neue Fenster-Management-Regeln als native Binär-Plugins direkt in seinen Kern. Und auch im hochskalierenden Web-Bereich greift dieses Muster: Der Webserver Nginx erlaubt es, rechenintensive Filter oder Security-Regeln von Drittanbietern als nativ kompilierte Dynamic Modules direkt in die Verarbeitungspipeline einzuhängen.

Das Geschäftsmodell hier: Die offene Kern-Plattform gewinnt massive Marktanteile, während spezialisierte Firmen kommerzielle, proprietäre Module in dieses Ökosystem verkaufen können.

Teil 3: Das doppelte Geheimnis – Industrielle Maßstäbe (Closed Source)

Das Prinzip der ABI-Kooperation entfaltet sich besonders ausgeprägt im rein proprietären (Closed-Source) Sektor. Hier greift das Prinzip der gegenseitigen IP-Abschirmung: Der Host-Entwickler gibt ausschließlich eine C/C++ Header-Datei (die ABI-Dokumentation) heraus. Es gibt keinen Quellcode – beide Seiten kommunizieren als kompilierte Blackboxen miteinander.

Dieses Modell sichert in der Industrie gigantische Märkte ab:

• Kreativindustrie (Audio/Video): Ein historisches Paradebeispiel ist die Musik-Software Cubase von Steinberg. Die Software ist strikt Closed Source, etablierte aber die VST-Schnittstelle (Virtual Studio Technology). Steinberg kennt die Mathematik fremder Audio-Filter nicht, und die Filter-Entwickler kennen Steinbergs Audio-Engine nicht. Sie tauschen über Opaque Pointers lediglich Audio-Puffer aus. So entstand ein Milliardenmarkt für Drittanbieter-Plugins.

• Automotive & Simulation: In der Fahrzeugentwicklung nutzen Hersteller und Zulieferer den FMI-Standard (Functional Mock-up Interface). Wenn ein Autokonzern eine Fahrzeug-Simulation in einem geschlossenen Host-System (wie MATLAB/Simulink) baut, übergibt ein Getriebehersteller sein mathematisches Modell lediglich als vorkompilierte Binärdatei (FMU). Die Host-Simulation füttert das Plugin via C-ABI mit Drehzahl und Temperatur und erhält physikalische Ergebnisse zurück. Die streng geheimen Reibungs-Algorithmen des Zulieferers bleiben unangetastet.

• Finanzwesen: Institutionelle Trading-Plattformen wie MetaTrader erlauben es, Analyse-Werkzeuge und Trading-Strategien als native .dll-Dateien einzubinden. Zu beachten ist dabei, dass MetaTrader primär eine eigene Skriptsprache (MQL4/5) anbietet; native DLLs sind eine ergänzende Erweiterungsoption für rechenintensive oder besonders schützenswerte Logik. Die Plattform leitet Börsendaten an das Plugin weiter; nach welcher geheimen Strategie der Bot kauft oder verkauft, bleibt das exklusive Firmengeheimnis des Drittanbieters.

Fazit: Das Plugin als wirtschaftliches und juristisches Schutzschild

Egal ob in einer quelloffenen Plattform oder in einer geschlossenen Industrie-Simulation: Ein Drittanbieter kann ein hochkomplexes, proprietäres Verfahren verkaufen, ohne sein Intellectual Property (IP) jemals im Quelltext offenzulegen.

Ein absoluter Schutz vor Reverse-Engineering ist eine bloße Binärdatei technisch zwar nicht – Tools wie Decompiler können Maschinencode wieder in Assembler übersetzen. Doch wirtschaftlich und juristisch reicht die Barriere meist aus: Das Zurückgewinnen hochoptimierter Mathematik aus maschinellen Registern ist ein extremer, oft unrentabler Aufwand. Zudem etabliert die Binärdatei eine klare juristische Grenze (Trade Secret), deren Brechen den Straftatbestand der Industriespionage erfüllt. Wo das nicht reicht, wird die Binärschnittstelle zusätzlich mit hardwarebasiertem DRM oder Code-Virtualisierung (Packer) versiegelt.

Die Kosten dieses Architektur-Modells sind hoch: Erhöhter Aufwand bei Debugging, strengste Anforderungen an Versionierung und null Toleranz für unsauberes Speichermanagement. Im Gegenzug entsteht jedoch ein extrem belastbares Ökosystem, in dem Implementierungskapital (der geheime Algorithmus) und Distribution (die Host-Plattform) völlig unabhängig voneinander skalieren und monetarisiert werden können.

Teil 4: Vereinfachende Standards – Alternativen zur rohen C-ABI

Frage: Gibt es vereinfachende Standards, die denselben IP-Schutz bieten wie die in Teil 3 beschriebene C-ABI, aber mit weniger Fehleranfälligkeit?

Die rohe C-ABI ist mächtig, aber gefährlich: Ein falsch verwalteter Pointer, ein Versionskonflikt beim Compiler oder eine unterschiedliche Calling Convention genügen, um das gesamte System zum Absturz zu bringen. Die Industrie hat auf diesen Schmerz reagiert und mehrere Abstraktionsschichten entwickelt, die denselben IP-Schutz bieten – mit deutlich sanfteren Kosten.

WebAssembly (WASM) + WASI

Das ist der aktuell stärkste Trend für neue Systeme. Das Plugin wird zu .wasm kompiliert und läuft in einer sandboxed virtuellen Maschine – vollständig plattformunabhängig, ohne geteilten Adressraum, ohne Speicherverwaltungsprobleme zwischen Host und Plugin. Der Host kontrolliert exakt, welche Ressourcen das Plugin sehen darf (Filesystem, Netzwerk, Systemaufrufe). Frameworks wie Extism bauen darauf auf und liefern ein generisches Plugin-System, das in nahezu jeder Host-Sprache funktioniert. IP-Schutz: WASM-Bytecode ist deutlich schwerer zu reverse-engineeren als natives x86, kein absoluter Schutz, aber eine höhere Hürde als eine nackte .so. Der Preis ist Laufzeit-Overhead durch die VM – für Echtzeit-Audio oder physikalische Simulation heute noch zu teuer, für alles andere zunehmend akzeptabel.

COM / DCOM (Windows-Welt)

Microsofts Component Object Model löst seit den 1990ern exakt dieses Problem: typsichere, versionierte Binärschnittstellen ohne Quellcode, mit definiertem Ownership-Modell (AddRef/Release) und maschinenlesbaren Interface-Beschreibungen (IDL/TLB). VST3 von Steinberg – der direkte Nachfolger der in Teil 3 beschriebenen VST-Schnittstelle – baut auf COM-ähnlichen Prinzipien auf und ist damit ein direktes Beispiel für die Ablösung der rohen C-ABI durch einen formalisierteren Standard im selben Ökosystem. Der Preis: primär Windows-zentriert, und das Objektmodell trägt historischen Ballast.

gRPC / Protobuf über lokalen Socket

Kein ABI-Ansatz im klassischen Sinne, aber in der Praxis weit verbreitet: Das Plugin läuft als eigenständiger Prozess, die Kommunikation erfolgt über ein maschinenlesbares Schema (.proto-Datei). Vollständige Sprachunabhängigkeit, triviales Versionieren über Feldnummern, automatisch generierte Clients und Server in Dutzenden Sprachen. IP-Schutz ist maximal – der Plugin-Prozess ist eine vollständige Blackbox. Für die Finanzwelt (MetaTrader-Szenario aus Teil 3) ist das ein realistischer Ansatz: Latenz im Sub-Millisekunden-Bereich ist dort weniger kritisch als bei Echtzeit-Audio. Für FMI-Simulation oder VST-Audio scheidet dieser Ansatz jedoch aufgrund der Prozess-Kommunikationskosten aus.

Bewertungsmatrix

Der Trend geht für neue Systeme klar Richtung WASM. Für latenz-kritische Industrieanwendungen – FMI-Simulation, VST-Audio, Automotive-Echtzeit – bleibt die C-ABI jedoch noch auf absehbare Zeit der Goldstandard. Kein vereinfachender Standard überwindet die grundlegende Physik: Wer nanosekunden-genaue Übergabe von Audiodaten oder Differentialgleichungen braucht, zahlt den Preis der rohen Schnittstelle.

Heute gibt es ein kurzes technisches Update zum aktuellen Stand unseres maßgeschneiderten UI-Toolkits.

Abb 1: Die aktuelle Testumgebung im nkrunner mit Fokus auf Fensterverwaltung und Rendering.

Der Entwicklungsschwerpunkt lag in den letzten Tagen auf der Fensterverwaltung und dem Rendering-System. Echte, belastbare Benutzeroberflächen bestehen selten nur aus flachen Elementen – sie benötigen tief verschachtelbare (nestable) Strukturen.

Dafür haben wir in unserem UI-Toolkit nun ein sauberes System für Masken und Viewports implementiert. Scrollbare Bereiche funktionieren jetzt zuverlässig: Sobald ein Child-Element den zugewiesenen Bereich seines Parent-Containers verlässt, wird es visuell und logisch korrekt abgeschnitten (Clipping).

Gleichzeitig lag ein extremer Fokus auf der Performance bei dynamischen Fenstergrößen. Egal wie komplex die Hierarchie der scrollbaren Viewports wird, das Rendering im nkrunner muss absolut flüssig bleiben. Die strikte Vorgabe lautet: Stabile 60 FPS. Das ist keine kosmetische Metrik, sondern elementar wichtig. Sobald ein Werkzeug ruckelt oder bei Größenänderungen des Fensters Framedrops zeigt, geht das Gefühl der direkten Kontrolle verloren.

Der nächste Schritt: Der Datenhub

Das Fundament für das visuelle Layout und das räumliche Eingrenzen (Maskierung) steht und läuft performant. Im nächsten Schritt geht es darum, die Elemente des UI-Toolkits mit echtem Leben zu füllen. Wir werden diese internen Zustände in einem zentralen Datenhub synchronisieren, um grafisches Rendering, Nutzereingaben und die tieferliegende Geschäftslogik sauber (und nebenläufig) miteinander zu verknüpfen.

Nach den Architekturanpassungen der letzten Wochen – insbesondere der Umstellung auf Parallelverarbeitung – ging es in den vergangenen Tagen an die spürbare Praxis: Interaktion und Performance unter echter Last.

Abb 1: Die Spatial UI beim Selektieren und Verschieben von massiven Objektmengen.

Tausende Objekte: Dragging und Lasso-Selektion

Es ist eine Sache, 2000+ Objekte stabil auf den Bildschirm zu zeichnen (wie in Version 0.11 getestet). Eine völlig andere ist es, sie flüssig bedienbar zu machen. Der Fokus lag in diesem Schritt auf der direkten Manipulation im Spatial Workspace.

Das Einfangen von Objekten per Lasso-Selektion und das anschließende Dragging (Verschieben) der gesamten Auswahl durch die Szenerie funktioniert nun absolut reibungslos. Selbst bei tausenden gleichzeitig bewegten Elementen bricht die Framerate nicht ein. Die strikte Trennung von visueller Darstellung und auswertbarer Geometrie (Picking-Logik) greift hier perfekt ineinander.

Skalierbare Texterfassung

Wer schon einmal eine UI-Engine gebaut hat, weiß: Text ist teuer. Deshalb haben wir die Skalierbarkeit bei der Texterfassung und dem Text-Rendering gezielt optimiert. Eingaben, Umbrüche und das Rendering vieler dynamischer Text-Nodes innerhalb der Virtual Windows verbrauchen nun spürbar weniger Ressourcen. Das gibt dem System den nötigen Spielraum, um auch komplexe Layouts performant zu halten.

Aufräumarbeiten und Modularisierung

Schneller Code entsteht selten im Chaos. Um diese Performance-Sprünge zu erreichen – und vor allem für die Zukunft wartbar zu halten –, standen massive Aufräumarbeiten an.

Getreu dem Motto "Orthogonal arbeiten" haben wir die Quellcodes besser aufgeteilt und die Engine stärker modularisiert. Zuständigkeiten sind nun noch schärfer voneinander getrennt. Das macht das System nicht nur effizienter in der Ausführung, sondern auch deutlich angenehmer in der Weiterentwicklung. Das Fundament trägt.

In der Theorie klingt Orthogonalität simpel: Zwei Dinge sind orthogonal, wenn Änderungen am einen das andere nicht beeinflussen. In der Praxis der Softwareentwicklung ist das oft das erste Prinzip, das für "schnelle Ergebnisse" geopfert wird. Das Ergebnis ist dann kein Werkzeug, sondern ein Knäuel aus Abhängigkeiten.

Die Illusion der Abkürzung

Häufig wird Code so geschrieben, dass er "praktisch" ist – ein globaler Zustand hier, eine kleine Querbeziehung da. Man spart sich im Moment drei Zeilen Code oder eine saubere Schnittstelle. Aber sobald man an Komponente A schraubt, fliegt einem Komponente B um die Ohren, die eigentlich gar nichts damit zu tun haben sollte. Das ist das Gegenteil von orthogonalem Arbeiten.

Wer orthogonal arbeitet, akzeptiert den initialen Mehraufwand für klare Trennungen. Das Ziel ist, dass ein Feature oder ein Bugfix eine lokale Angelegenheit bleibt.

Beispiele aus der Praxis

Ein gutes System zeigt diese Trennung in seiner Architektur:

1. Rendering vs. Picking: Wie in meiner aktuellen Engine umgesetzt, sollte das Sichtbare vom Auswertbaren getrennt sein. Ein eigener Picking-Pass sorgt dafür, dass die grafische Finesse keine Auswirkung auf die Treffsicherheit der Maus hat.
2. Shader-Logik: Statt für jedes Backend manuell zu frickeln, nutzt man einen zentralen Pfad und moderne Shader-Compiler. Die Host-Seite bleibt von der GPU-Logik (GLSL) komplett getrennt.
3. Zustand und UI: Hintergrundarbeit gehört in eigene Threads, damit die UI nicht stottert. Sobald sich die Berechnung in den UI-Takt frisst, ist die Orthogonalität verloren.

Warum das wichtig ist

Wenn man nicht orthogonal arbeitet, steigt die kognitive Last exponentiell an. Man kann sich nicht mehr auf eine Sache konzentrieren, sondern muss das gesamte System im Kopf behalten, um keine Lawine an Fehlern auszulösen.

Orthogonalität bedeutet Respekt vor der eigenen Zeit und der Zeit derer, die den Code später lesen müssen. Es geht darum, Verantwortung für die Folgen einer Änderung zu übernehmen. Wer behauptet, "schnell fertig" zu sein, indem er alles mit allem verheiratet, lügt sich selbst in die Tasche. Echte Effizienz entsteht durch Unabhängigkeit.

Das heutige Update auf Version 0.11 bringt tiefgreifende Änderungen an der Engine-Architektur. Während die visuelle Seite der Spatial UI weiter wächst, stand diesmal die Performance-Analyse unter erschwerten Bedingungen im Vordergrund.

Abb 1: Die Engine bei über 2000 aktiven Render-Objekten.

Das Test-System: 100 % On-Chip

Um die Leistungswerte realistisch einzuschätzen, hier die Hardware-Konfiguration. Wichtigster Punkt: Es ist keine dedizierte Grafikkarte verbaut. Das System verfügt über keinen PCIe-Grafikbeschleuniger; die gesamte Bildausgabe und Berechnung erfolgt über die integrierte Einheit des Prozes1rs.

• CPU: AMD Ryzen 7 5700G (8 Kerne, 16 Threads, Zen 3 Architektur)
• Integrierte GPU: AMD Radeon™ Graphics (Vega 8)
  • Grafikkerne: 8
  • Taktfrequenz: 2000 MHz
  • Speicher: Shared Memory (nutzt einen Teil des System-RAMs)
• RAM: 32 GB Corsair Vengeance LPX DDR4-3200
• Mainboard: ASUS ROG Strix B550-F Gaming

Aktuell liegen wir bei >20 FPS bei >2000 aktiven Render-Objekten. Dass wir diese Stabilität rein über die iGPU erreichen, ohne dass eine physische Grafikkarte im Slot steckt, ist ein ehrliches und brauchbares Ergebnis für den aktuellen Optimierungsstand.

Umstellung auf Parallelverarbeitung

Der wichtigste technische Schritt in Version 0.11 war die Umstellung auf Parallelverarbeitung. Wir nutzen nun das Threading-Modell, um die Vorbereitung der Render-Daten und die Objekt-Logik massiv zu parallelisieren.

Dadurch verhindern wir, dass die CPU zum Engpass wird. Die 2000+ Objekte werden effizient verwaltet, sodass der Flaschenhals nun fast ausschließlich bei der Füllrate und den Draw-Calls der integrierten Radeon-Einheit liegt.

*Abb 2: Auch bei hoher Last auf der integrierten Grafik

Linus Torvalds wird ein Satz zugeschrieben, der trockener kaum klingen könnte und gerade deshalb so gut ist: „We don't break user space.“ Kein Zukunftsgeflimmer, kein Produktsprech, kein Gerede von Disruption, sondern bloß eine knappe Regel mit erstaunlich viel Anstand. Gemeint ist im Kern, dass interne Änderungen nicht einfach dazu führen dürfen, dass draußen funktionierende Programme, Skripte und Arbeitsabläufe plötzlich kaputtgehen.

Das klingt zunächst nach einer rein technischen Maxime aus der Linux-Welt, ist aber eigentlich sehr viel allgemeiner. „User space“ meint dort die Welt, in der Menschen tatsächlich arbeiten: Tools, Shells, Editoren, Dienste, Routinen, gewachsene Systeme. Und genau diese Welt ist es, die in vielen Projekten erstaunlich wenig Respekt erfährt, sobald irgendwo jemand beschließt, nun werde „endlich mal aufgeräumt“.

Der Reiz dieses Satzes liegt darin, dass er eine unangenehme Wahrheit ausspricht: Sobald Leute sich auf ein Verhalten verlassen, ist dieses Verhalten real. Es spielt dann nur noch begrenzt eine Rolle, ob eine Schnittstelle intern schön ist, ob ein Flag historisch gewachsen oder ein Dateiformat nicht mehr elegant wirkt. Irgendwo hängt fast immer ein Skript daran, ein Build, ein Server oder schlicht ein Mensch, der sich einen Ablauf über Jahre eingeprägt hat. Von innen sieht das schnell wie Altlast aus; von außen ist es oft einfach etwas, das zuverlässig funktioniert.

Genau hier beginnt der Unterschied zwischen technischer Eitelkeit und technischer Reife. Es ist leicht, Dinge neu und sauber zu entwerfen, wenn man so tut, als gäbe es keine Vergangenheit. Schwierig ist es, ein System zu verbessern, ohne dabei die Kosten der eigenen Verbesserung nach außen abzuwälzen. Vieles, was als Modernisierung verkauft wird, ist in Wahrheit bloß eine Verlagerung von Aufwand: Innen wurde etwas hübscher, außen brechen Dokumentation, Gewohnheiten und Automatismen.

Darum ist Kompatibilität auch keine feige Tugend und kein Ausdruck von Ideenarmut. Sie ist Respekt vor fremder Zeit. Wer funktionierende Nutzung erhält, schützt nicht nur Code, sondern investierte Lebenszeit, eingeübte Handgriffe und oft genug ganze Produktionsabläufe. Das ist unerquicklich, weil es Mühe macht. Man muss Übergänge bauen, unschöne Sonderfälle mitschleppen, Ersatzpfade anbieten und manchmal den eigenen Wunsch nach totaler Bereinigung zurückstellen. Aber genau darin liegt oft die eigentliche Ingenieursleistung.

Natürlich heißt das nicht, dass niemals etwas verschwinden darf. Jedes System braucht irgendwann Schnitte, sonst erstickt es an seiner eigenen Geschichte. Nur ist eben nicht jeder Bruch schon deshalb legitim, weil die neue Lösung dem Entwickler besser gefällt. Wenn man etwas ändern muss, dann möglichst mit Begründung, Vorlauf und einem brauchbaren Weg von alt nach neu. Nicht jeder Bruch ist vermeidbar, aber die Gleichgültigkeit gegenüber seinen Folgen wäre es oft schon.

Vielleicht gefällt mir dieser Satz deshalb so gut, weil er so wenig Theater macht. Er behauptet nicht, die Welt neu zu erfinden, sondern erinnert an etwas viel Bodenständigeres: Wenn andere Menschen auf einem System aufbauen, entsteht Verantwortung. Das ist keine spektakuläre Einsicht, aber eine, von der ein erstaunlich großer Teil der Softwarewelt profitieren würde.

Heute möchte ich euch einen Blick auf den aktuellen Stand des Interfaces werfen lassen. Wir haben nun eine funktionierende, räumliche Benutzeroberfläche (Spatial UI), die komplett in unserem Stack gerendert wird.

Hier ist ein aktueller Screenshot aus der Engine:

Abb 1: Unsere räumliche Benutzeroberfläche mit aktiven Text-Modulen, Selektions-Pfeilen und globalem Koordinatensystem.

Was gibt es Neues zu sehen?

Wie man auf dem Screenshot gut erkennen kann, verschmelzen 2D-UI-Konzepte immer mehr mit der 3D-Welt. Die wichtigsten Neuerungen auf einen Blick:

1. Virtual Windows: Wir haben mehrere schwebende Panels im Raum platziert ("Mitarbeiter Profil", "Projekt Übersicht", "Aufgabenliste"). Diese Panels sind keine statischen Texturen, sondern echte 3D-Objekte, die im Raum frei bewegt und skaliert werden können.
2. Der integrierte Texteditor: Das gelb umrandete Panel rechts ("Textobjekt Test") zeigt unseren neuen Texteditor in Aktion. Wie im Textfeld beschrieben:
   • Mit F2 startet man den Edit-Mode direkt im 3D-Raum.
   • Strg+W schaltet den Wordwrap um.
   • Strg+P öffnet zusätzlich unser HUD-Eingabefeld.
3. Selektion & Snapping: Die gelben und grünen Pfeile, die vom Zentrum ausgehen, visualisieren unser neues Navigations- und Snapping-System. Objekte "wissen", wo sie sich relativ zueinander befinden. Ein Constraint-System sorgt dafür, dass Fenster logisch aneinander andocken können, ohne sich unschön zu überlappen.
4. Das globale Koordinatensystem: Die X-, Y- und Z-Achsen helfen bei der Orientierung, während die Kamera (mit Maus und Numpad steuerbar) stufenlos heranzoomen oder um die Panels kreisen kann.

Wie geht es weiter?

Das Fundament steht! Das Rendering über den Render-Pass funktioniert performant. Wie bereits im Editor-Testfenster auf dem Screenshot angeteasert, lauten die nächsten Ziele:

• Verfeinerung der Mauslogik (besseres Drag & Drop Verhalten).
• "Echte" Inner-Frame-Inputs für die Virtual Windows (z.B. Buttons klicken oder Text markieren).
• Erweiterung der Undo/Redo-Historie für komplexe Layout-Änderungen.

Bleibt dran, wir nähern uns mit großen Schritten einem voll funktionsfähigen Spatial-Workspace!

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 und Änderungen wieder zurücknehmen muss. Genau dort trennt sich eine bloße Oberfläche von einem echten Werkzeug.

In meinem aktuellen Engine-Projekt arbeite ich genau in diesem Bereich. Der Kern liegt nicht in einem Satz fertiger Controls, sondern in den technischen Schichten darunter: Objektmodell, Eingabeverarbeitung, zielgenaues Anvisieren (Picking) und Nebenläufigkeit.

Präzises Picking statt reiner Optik

Sichtbare Geometrie und auswertbare Geometrie sind zwei verschiedene Probleme. Ein Element kann optisch korrekt sein und trotzdem für den Nutzer schlecht treffbar. Deshalb nutzt das Projekt eine strikt vom visuellen Rendering getrennte Logik. Die Bedienung hängt daran, dass Dinge pixelgenau und zuverlässig adressierbar bleiben, unbeeinflusst von komplexen visuellen Effekten, Transparenzen oder Überdeckungen.

Zentrale Shader-Architektur & Pipeline

Die grafische Darstellung wird über eine zentrale Architektur gesteuert. Aus einer zentralen Beschreibung werden die passenden Artefakte generiert. Primitive, Tiefentests und Layouts werden pro Pfad explizit gesetzt. Das ist zwingend, denn transparente Überlagerungen, Texte und 3D-Körper haben völlig unterschiedliche Anforderungen an die Grafikkarte.

Nebenläufigkeit ohne Ruckeln

Die wichtigste Regel für flüssige Werkzeuge: Hintergrundarbeit darf den UI-Takt niemals blockieren. Sobald Berechnungen neben den Eingaben laufen, muss der Haupt-Thread frei bleiben. Die Architektur nutzt getrennte Worker-Prozesse, damit die Oberfläche mit konstanten Framerates reagiert, völlig unabhängig davon, wie viel Last das System im Hintergrund verarbeitet.

Der Wert dieses Projekts liegt nicht in einer Sammlung von Einzel-Features, sondern im architektonischen Fundament. Wer diese Probleme in eine gemeinsame, stabile Struktur zwingt, baut ein belastbares Werkzeug.