Skip to main content

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-client to 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.