Vulkan plus in-process WebRTC for desktop screen sharing
Context
A client needed native Mac and Windows apps with real-time screen sharing. Electron was too heavy; the rendering path needed GPU access. WebRTC was the transport layer of choice for latency.
Decision
Build a shared C++17 core using Vulkan 1.0 for rendering and embed WebRTC in-process for capture and transport.
Alternatives Considered
Electron with Chromium WebRTC
Pros
- WebRTC built in
- Faster initial prototype
Cons
- Large binary, limited GPU control
- Harder to meet performance targets on older Macs
Platform-native graphics (Metal + D3D)
Pros
- Best performance on each platform
Cons
- Two rendering codebases to maintain
- Harder to hire for and test
Separate WebRTC media server process
Pros
- Isolates crashes in the media stack
Cons
- IPC overhead on every frame
- More complex deployment
Reasoning
Vulkan via MoltenVK on Mac and native Vulkan on Windows gave one rendering path. In-process WebRTC avoided frame copies across process boundaries. The trade-off — more C++ complexity upfront — matched the client's need for a long-lived product, not a quick demo.