Consolidate smart source websocket subscriptions.

[michelinewu]

Use ReactiveDataService for smart source socket events

Issue

Each SmartBrowserSourceManager independently subscribed to the websocket and called visionService.ensureRunning() on init. With N smart browser sources active, this created N parallel socket subscriptions all listening for the same visionEvent/userStateUpdated events and N redundant Vision startup calls.

Fix

Moved event forwarding and Vision startup out of SmartBrowserSourceManager and into ReactiveDataService, which already had a single socket subscription.

Performance comparison

Metric	Before	After
Websocket subscriptions	N (one per smart source)	1
sendMessage calls per event	1 per source (each source messages itself)	1 per source (centralized fan-out, same count)
visionService.ensureRunning() calls on startup	N (once per source init)	1–2 (guarded, at login + first source registration, other calls when adding sources are untouched)
destroy() / unsubscribe overhead	N (one socketSub.unsubscribe() per source)	0

Renderer process performance

SmartBrowserSourceManager runs in the renderer process. Every websocketService.socketEvent subscription it created was backed by an IPC listener — each incoming websocket event triggered a separate IPC message delivery for each subscribed source.

Scenario	IPC messages per websocket event (before)	IPC messages per websocket event (after)
1 smart source active	1	1
3 smart sources active	3	1
5 smart sources active	5	1

With the subscription consolidated into ReactiveDataService (main process side), the IPC crossing happens once per event regardless of how many smart sources are loaded. The renderer receives a single delivery; forwardEventToSources() then fans out via obsSource.sendMessage(), which is a synchronous in-process call with no further IPC overhead.

Additionally, each visionService.ensureRunning() call from a source manager on init crossed the IPC boundary to check and start Vision. The ensureVisionRunning() guard reads isRunning/isStarting from local state before calling through, eliminating redundant IPC round-trips when Vision is already up.

[Copilot]

Pull request overview

This PR consolidates Smart Browser Source websocket event handling and Vision startup coordination into ReactiveDataService to avoid per-source websocket subscriptions (and the associated IPC overhead) in the renderer process.

Changes:

• Added a SourcesViews.getSmartSources() helper to retrieve smart browser sources by propertiesManagerType.
• Removed per-source websocket subscription + visionService.ensureRunning() startup from SmartBrowserSourceManager.
• Subscribed once in ReactiveDataService to forward visionEvent / userStateUpdated events to all smart sources, and added a guard to reduce redundant Vision startup calls.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
app/services/sources/sources.ts	Adds a view helper to find smart browser sources by manager type for centralized fan-out.
app/services/sources/properties-managers/smart-browser-source-manager.ts	Removes per-source websocket subscription and Vision startup, leaving URL normalization only.
app/services/reactive-data/index.ts	Centralizes websocket forwarding to smart sources and introduces guarded Vision startup logic.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bundlemon]

BundleMon

Files added (4)

Status	Path	Size	Limits
✅	renderer.(hash).js	+7.74MB	-
✅	vendors~renderer.(hash).js	+4.67MB	-
✅	updater.js	+115.29KB	-
✅	guest-api.js	+40.23KB	-

Total files change +12.56MB

Final result: ✅

View report in BundleMon website ➡️

---

Current branch size history

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.