Laminar Research arbeitet an einer größeren Modernisierung der X-Plane-Schnittstellen für Benutzeroberflächen und Avionik. In einem Beitrag im X-Plane Developer Blog hat Ben Supnik skizziert, wohin sich das SDK entwickeln soll. Im Kern geht es um ein Thema, das viele Nutzer nicht direkt sehen, das aber langfristig durchaus spürbar werden kann: Wie Plugins, Cockpitanzeigen und Zusatzsoftware ihre Oberflächen in X-Plane zeichnen.
Bisher hängt in diesem Bereich vieles an OpenGL. Das ist historisch gewachsen, aber zunehmend ein Bremsklotz. X-Plane selbst ist längst auf moderne Grafik-Backends wie Vulkan ausgerichtet. Wenn Plugins weiterhin über OpenGL zeichnen, muss X-Plane diese Inhalte technisch aufwendig in die moderne Rendering-Pipeline einbinden. Genau diese Brücke kostet Leistung und lässt sich laut Supnik nur schwer oder gar nicht sinnvoll auf mehrere Prozessorkerne verteilen.
Die neue Roadmap soll deshalb zwei Dinge erreichen: bessere Performance und einfachere Entwicklung. Entwickler sollen künftig Oberflächen und Avionik bauen können, ohne sich direkt mit OpenGL beschäftigen zu müssen. Gleichzeitig will Laminar Werkzeuge anbieten, die näher an dem liegen, was Add-on-Entwickler tatsächlich brauchen: Displays, Schriften, Linien, Formen, Texturen, Touchbereiche und moderne Plugin-Fenster.
Panel Graphics: Laminar baut eine native Zeichen-API
Der wichtigste Baustein ist eine neue API namens XPLM Panel Graphics. Dabei handelt es sich um eine native Zeichen-Schnittstelle innerhalb des X-Plane SDK. Sie ist nicht als allgemeine 3D-Grafik-API gedacht, sondern gezielt für Avionik, Panels und Plugin-Fenster.
Entwickler sollen damit unter anderem Vektorgrafiken, gefüllte und umrandete Formen, anti-aliased Linien, TrueType-Schriften, Texturen, Clipping, 2D-Transformationen und interaktive Bereiche zeichnen können. Also genau die Dinge, die man für moderne Flugzeuginstrumente, Displays oder Touchscreens braucht. Auch das Wiederverwenden bereits erzeugter Grafikbestandteile ist vorgesehen, damit komplexe Anzeigen effizienter gerendert werden können.
Der entscheidende Punkt: Diese Panel-Grafik wird direkt von X-Plane selbst über Vulkan umgesetzt. Damit kann Laminar die Darstellung viel enger in die eigene Rendering-Engine integrieren als bei externen Lösungen. Das soll nicht nur schneller sein, sondern perspektivisch auch besser zu einer Multicore-Architektur passen.
Supnik erklärt auch, warum Laminar dafür eine eigene Lösung baut. Alternativen seien zu schwer sauber in X-Plane zu integrieren, andere wiederum zu spezialisiert oder für Avionik nicht ausreichend geeignet. Die eigene API sei daher der Versuch, genau die Mitte zu treffen: leistungsnah genug für X-Plane, aber hoch genug abstrahiert, damit Entwickler nicht wieder bei Low-Level-Grafikarbeit landen.
ImGui bleibt wichtig, wird aber besser angebunden
Ein zweiter großer Punkt betrifft Dear ImGui. Dear ImGui ist eine sehr beliebte Open-Source-Bibliothek, mit der Entwickler schnell grafische Bedienoberflächen für Tools, Debug-Fenster, Editoren oder Plugins bauen können. Der Clou: Die Oberfläche wird direkt aus dem Programmcode heraus erzeugt, ohne dass man vorher ein klassisches UI mit Layout-Dateien, Designer-Tools oder großem Framework-Gedöns bauen muss.Viele Plugin-Entwickler nutzen ImGui bereits heute, weil es schnell, praktisch und deutlich moderner ist als die alten Widget-APIs aus früheren X-Plane-Zeiten. Laminar will ImGui aber nicht direkt in das SDK einbauen. Der Grund ist vor allem technischer Natur: ImGui ist stark auf C++ ausgelegt, während das X-Plane SDK traditionell C-Schnittstellen anbietet. Eine offizielle C-Variante würde viele ImGui-Erweiterungen und Custom Widgets erschweren.
Stattdessen soll X-Plane künftig ImGui-Zeichenlisten nativ darstellen können. Vereinfacht gesagt: Das Plugin erzeugt weiterhin seine Oberfläche mit ImGui, aber die eigentliche Darstellung läuft nicht mehr über OpenGL, sondern über die neue Panel-Grafik-Schnittstelle von X-Plane. Für Entwickler soll der Umstieg überschaubar bleiben. Supnik spricht davon, dass im Wesentlichen der Zeichentyp eines XPLM-Fensters geändert und der bisherige OpenGL-Zeichencode durch wenige Panel-Graphics-Aufrufe ersetzt werden müsste.
Für uns X-Plane-Piloten ist das unspektakulär formuliert, aber potenziell relevant: Viele Plugin-Fenster könnten mittelfristig effizienter laufen und besser zur modernen X-Plane-Grafikpipeline passen.
Plugin-Fenster im Browser
Als dritte Säule nennt Supnik browserbasierte Fenster. Plugins sollen künftig Fenster erzeugen können, deren Inhalt über einen Browser gerendert wird. X-Plane nutzt dafür CEF, also Chromium Embedded Framework, das bereits mitgeliefert wird.
Das öffnet für Entwickler einen sehr bekannten Werkzeugkasten: HTML, CSS und JavaScript. Gerade für komplexere Benutzeroberflächen, Einstellungen, Shops, Karten, Konfiguratoren oder moderne App-ähnliche Plugin-Fenster kann das attraktiv sein. Eine begrenzte Kommunikation zwischen Plugin und Browserinhalt ist ebenfalls vorgesehen.
Ganz ohne Einschränkungen kommt dieser Ansatz aber nicht. Supnik weist ausdrücklich auf Sicherheitsfragen hin. Ein Browserfenster innerhalb eines Plugins sei kein sicherer Kontext für sensible Eingaben. Anders gesagt: Für eine Wetter-App, ein Dispatch-Tool oder ein Aircraft-Config-Menü mag das sinnvoll sein. Für das Krypto-Wallet im Cockpit eher nicht. Wobei man fairerweise sagen muss: Wer seine Seed Phrase ins FMC holen will, hat vermutlich sein Leben nicht mehr im Griff, hehe.
Keine öffentliche X-Plane-UI als SDK-Baustein
Interessant ist auch, was Laminar vorerst nicht macht. X-Plane besitzt intern ein eigenes UI-Framework, das unter anderem für Plane Maker, X-Plane Mobile und die Benutzeroberfläche von X-Plane 11 entstanden ist. Laminar hatte offenbar überlegt, dieses Framework auch Entwicklern zugänglich zu machen.
Davon nimmt Supnik aber Abstand. Die interne UI sei nicht reif genug für eine stabile öffentliche API, außerdem recht breit und damit schwer dauerhaft kompatibel zu halten. Dazu komme, dass es keine große Entwickler-Community rund um dieses interne System gebe. ImGui und Browser-Technologien seien für externe Entwickler schlicht vertrauter und besser anschlussfähig.
Was heißt das für Add-ons?
Kurzfristig müssen X-Plane-Nutzer vermutlich nicht mit sichtbaren Änderungen rechnen. Supnik nennt auch keinen festen Veröffentlichungstermin für die Panel-Graphics-API. Interessant ist die Änderung eher für Entwicklerinnen und Entwickler. Dafür erwartet er eine Art Developer Preview für Laminar-Entwicklerkreise spätestens im Sommer. ImGui-Unterstützung ist laut Beitrag aktuell für X-Plane 12.5.0 eingeplant, kann sich aber noch verschieben.
Für Add-on-Entwickler ist die Richtung trotzdem klar. Wer neue Flugzeuge, Avioniksysteme oder Plugins plant, sollte sich laut Supnik bereits jetzt überlegen, ob künftig Panel Graphics, ImGui oder browserbasierte Fenster die passende Grundlage sind. Bestehende ImGui-Plugins könnten später auf die native Darstellung umgestellt werden. Middleware-Entwickler sollen prüfen, welche ihrer Schnittstellen sich langfristig auf Panel Graphics migrieren lassen.
Für X-Plane-Nutzer ist das kein Feature, das man sofort im Changelog als neue Wolkenfarbe oder zusätzliche Taste im Menü erkennt. Es ist eher Arbeit am Fundament. Aber genau dort entscheidet sich, wie gut komplexe Add-ons in Zukunft mit X-Plane harmonieren. Moderne Avionik, performante Plugin-Fenster und weniger OpenGL-Altlasten sind keine lauten Marketingpunkte, können aber am Ende sehr konkrete Auswirkungen haben: bessere Bildraten, weniger technische Reibung und mehr Spielraum für Entwickler.
