Innerframe-Zooming, Nested Viewports und das Chessboard

Ein globaler Kamera-Zoom stößt bei fensterbasierten 3D-Interfaces schnell an Grenzen. Wenn ein Formular detaillierte Informationen enthält, ist ein gezieltes Vergrößern des Inhalts oft sinnvoller, als die Kameraposition im Raum zu verändern.

Daraus ergab sich die Notwendigkeit für lokales Innerframe-Zooming, verschachtelte Viewports (Nested Scrolling) sowie neue Test-Objekte wie das Chessboard.

Abb 1: Die Benutzeroberfläche mit individuell skalierten Innerframes. Jedes Fenster hält seinen eigenen Zoom-Faktor.

Innerframe-Zooming: Lokaler Maßstab

Jedes virtuelle Fenster besitzt nun einen eigenen zoomScale-Wert im Datenmodell. Mit Ctrl + Mausrad über einem Fenster wird isoliert dessen Inhalt skaliert. Alternativ lässt sich das fokussierte Fenster über die Tastatur mit Ctrl + Numpad+ und Ctrl + Numpad- vergrößern oder verkleinern.

Ein Blick unter die Haube: Die Skalierung erfolgt nicht durch nachträgliches Strecken einer gerenderten Textur. Der Zoom-Faktor wird direkt in den Kontext des Layout-Systems übergeben. Bei der Berechnung des UI-Gitters durch den Worker-Thread werden Parameter wie Margins, Paddings und Font-Metriken mit diesem Faktor multipliziert. Textelemente, die auf Signed Distance Fields (SDF) basieren, werden so mathematisch neu berechnet und bleiben scharf. Fällt der Inhalt aus dem sichtbaren Bereich, werden Scrollbars aktiviert.

Nested Viewports und Nested Scrolling

Um skalierte Inhalte an den Fensterkanten korrekt abzuschneiden, wurde ein System für Nested Viewports (verschachtelte Ansichtsbereiche) implementiert. Wenn ein UI-Element aus einem scrollbaren Formular besteht, das wiederum ein scrollbares Text-Editor-Feld enthält, muss das Clipping über mehrere Ebenen hinweg korrekt berechnet werden.

Abb 2: Nested Scrolling in Aktion: Ein scrollbarer Editor-Bereich innerhalb eines scrollbaren Hauptformulars.

Durch das angepasste Event-Routing entsteht so ein funktionierendes Nested Scrolling: Die Scroll-Eingabe wird dem Viewport zugeordnet, über dem sich der Mauszeiger befindet. Scrollt der Nutzer über dem Editor-Feld, bewegt sich nur dessen Text. Scrollt der Nutzer im Rest des Formulars, bewegt sich die gesamte Maske.

Ein Blick unter die Haube: Die Umsetzung basiert auf einer Stack-Architektur und geometrischen Schnittmengen. Jedes scrollbare Element legt seine Begrenzungen auf einen Stapel. Liegt ein Child-Element in einem Parent-Element, berechnet das System die Schnittmenge beider Rechtecke (intersect). Nur Render-Befehle, die innerhalb dieser kombinierten Grenzen liegen, werden an den Fragment-Shader der Grafikkarte weitergegeben.

Neue Visualisierung: Das Chessboard

Zur Visualisierung von Datenrastern und Flächen wurde ein Schachbrett-Objekt (wokChessboard) implementiert. Dieses dient gleichzeitig als technischer Testfall für zwei Aspekte:

1. GPU-Batching: Das Schachbrett berechnet sein Muster zustandsfrei in einem separaten Datensatz für die Worker-Threads. Die Performance bleibt dadurch auch bei mehreren parallel angezeigten Instanzen konstant.
2. Proportionssperre (Uniform Resize): Ein Raster muss beim Skalieren quadratisch bleiben und darf sich bei Maus-Interaktionen nicht verzerren.

Ein Blick unter die Haube: Für diese Einschränkung wurde die Interaktions-Logik um eine Status-Variable (resizeUniform). Zieht der Nutzer den Maus-Cursor am Fensterrahmen, entstehen Deltas für die X- und Y-Achse. Ist das Flag aktiv, wird der größere der beiden Werte auf Breite und Höhe gleichermaßen angewendet, bevor die Transformations-Matrix aktualisiert wird. Das Grafik-Objekt selbst bleibt dabei von Logik bezüglich des Seitenverhältnisses befreit, da diese in der zentralen Interaktions-Schicht verbleibt.

Dies bildet die technische Grundlage für die Darstellung und Interaktion mit weiteren proportional gebundenen Datenansichten.