Optimize Ingame Overlay Performance via Centralized WebSocket & PostMessage Architecture

[breadles5]

description

In the current architecture of the /api/ingame endpoint, the parent Electron window instantiates multiple overlays as <iframe> elements. Currently, each of these overlays independently establishes its own WebSocket connection to the Tosu API via WebSocketManager.

The Problem

This 1:N architecture creates significant performance bottlenecks:

1. Redundant Network Activity: Multiple persistent WebSocket connections are created for identical or overlapping data streams.
2. Serialization Overhead: Every active overlay performs expensive JSON.parse() operations on the same data payload.
3. CPU Constraint: The Electron-based ingame overlay already incurs overhead; managing multiple independent socket threads and parsing logic exacerbates CPU usage, potentially affecting game performance.

Proposed Solution

Refactor ingame.js to act as a centralized data broker. Instead of each child iframe managing its own connection, the parent window should maintain a single WebSocket connection and distribute data to child overlays via window.postMessage.

Implementation Details

1. Parent Window (ingame.js)

• Initialize overlay iframes with a specific flag (e.g., ?ingame=true).
• Maintain a single connection to the Tosu WebSocket API.
• Aggregate a superset of all filters requested by active overlays.
• Upon receiving a message, broadcast the data object to all child iframes using postMessage.

2. Client Library (socket.js)

• Modify the createConnection method to check for the ingame=true URL parameter.
• If present, bypass WebSocket creation and instead add a window.addEventListener('message', ...) listener.
• Accept the pre-parsed data object directly from the parent using the structured clone algorithm.

3. Filter Strategy

• The parent will subscribe to the superset of all required data to avoid complex per-child filtering logic in the main thread.
• Trade-off: We sacrifice negligible memory and internal bandwidth (passing unnecessary fields to some overlays) to save significant CPU cycles (avoiding deep object filtering/cloning).

Backward Compatibility

Legacy overlays (e.g., those built for gosumemory or using hardcoded socket logic) that do not support the ingame=true protocol will ignore the parameter and continue to establish their own WebSocket connections. This ensures no breaking changes for existing community content.

Expected Results

• Reduction in JSON.parse ops: From N (number of overlays) to 1 + M (where M is the number of legacy overlays).
• Lower CPU Usage: Critical for ensuring the overlay does not impact osu! frame times.
• Simplified Network Topology: Single point of entry for ingame data.

[cyperdark]

@breadles5 any news on this one?

[breadles5]

I've been really busy with a lot of IRL stuff, so I've had little time to work on this. My initial attempt at an implementation did work, but it wasn't as optimized as I would've liked. Given that it didn't meet the quality bar I set for myself going in and that I'll be tied up for the foreseeable future, I'll leave it to the tosu devs to decide whether they want to implement this or just close the issue.