Architecture overview
GlassOut is a hub-and-spoke system. One component — the engine — does all the heavy lifting with the sim. Everything else is a client that talks to it over WebSocket + HTTP.
┌─────────────┐ ┌──────────────┐ ┌──────────────────────┐
│ Desktop │ │ Mobile app │ │ Third-party app / │
│ app │ │ iOS/Android │ │ browser / home- │
│ │ │ │ │ cockpit integration │
└──────┬──────┘ └───────┬──────┘ └──────────┬───────────┘
│ │ │
│ WebSocket + HTTP (LAN / localhost)
▼ ▼ ▼
┌───────────────────────────────────────────┐
│ glassout-engine.exe (headless) │
│ │
│ captures panels ─ compresses pixels │
│ HTTP + WebSocket ─ mDNS discovery │
└───────────────────┬───────────────────────┘
│
▼
Microsoft Flight Simulator (2024 / 2020)
The engine
glassout-engine.exe is the only component that touches MSFS. Everything
else — the desktop app, the phone, your third-party app — is a client that
consumes what it produces.
It's a single self-contained executable that:
- Captures instrument panels live from Microsoft Flight Simulator 2024 and 2020 (DirectX 12 is required).
- JPEG-encodes each panel on the CPU via libjpeg-turbo (no video encoder, no GPU load). Quality is adaptive per subscriber — the server keeps a per-client level on a discrete ladder (Q40 / Q60 / Q75 / Q85) and steps each client up or down based on its WebSocket buffer state.
- Serves panels as HTML viewers over HTTP and as binary streams over WebSocket.
- Advertises itself on the LAN via mDNS so mobile devices can find it with no manual configuration.
Typical resource usage (4-panel WT G3000 cockpit, one PC + one phone viewing): ~4% of one CPU core, ~90 MB of RAM, ~25 Mbps total network out. The desktop app on top of that runs at ~3% CPU and ~245 MB RAM (Electron overhead).
Lifecycle:
- The engine is singleton: only one copy runs at a time. A discovery file lets clients find the running instance instead of spawning duplicates.
- It runs while at least one driver app (the desktop app or a third-party integration) is connected, and shuts down ~5 seconds after the last one leaves. Viewer-only clients (browsers, mobile, OBS sources) never keep it alive on their own.
The SDK (glassout-client)
TypeScript SDK used by the desktop app and by any third-party app that wants a typed, event-driven interface to the engine. It handles:
- Discovery of a running engine.
- Auto-spawn (optionally with UAC elevation).
- WebSocket protocol — text frames for state/panels/configs, binary frames carrying one self-contained JPEG per panel per tick.
- Reconnection with exponential backoff and subscription restoration.
- URL builders for panel / fragment / template viewer URLs.
See the SDK guide, the WebSocket protocol for the wire format, and the HTTP API for the viewer endpoints.
Desktop app
Windows desktop app that:
- Uses
glassout-clientto talk to the engine. - Renders panels via
<iframe src="http://localhost:8787/panel/<id>">. The engine serves a self-contained HTML viewer at that URL. - Manages profiles, multi-window layouts, license activation, and auto-updates.
Mobile app
iOS and Android app that:
- Discovers the engine via Bonjour / mDNS, with a manual-IP fallback.
- Renders panels full-screen, with touch forwarded back to the sim.
- Keeps the screen awake while a panel is displayed.
Why this split?
- Reuse. One capture pipeline powers the desktop app, phone, web browsers, and third-party integrations simultaneously.
- Embed-friendly. Third-party MSFS add-ons can use GlassOut panels
inside their own UI with nothing more than an
<iframe>. - Headless OK. You don't need the GlassOut desktop app at all — the engine alone is enough to power a home-cockpit setup that auto-starts with Windows and serves panels to a tablet.