Native background WebContentsView suspension to drastically reduce RAM

(#4197) Feature Answered channels notifications performance

2 votes Locked

Current problem

Running multiple accounts or switching between instances currently keeps all WebContentsView renderers fully active in the background. Because Electron runs full Chromium instances, this causes heavy RAM and CPU consumption even when background accounts/tabs are completely idle.

Proposed change

Implement automatic background view suspension natively under the hood: Automatic Background Suspension: When an account or view is pushed to the background, automatically set setVisible(false) and pause JS loops with IPC (Inter-Process Communication). Lightweight Core: Background instances keep only a minimal WebSocket connection open for pings and real-time notifications. Instant Unfreeze: Clicking on a background account or tab instantly restores the renderer with zero delay.

Platform

macOS, Windows, Linux, Web, Self-hosting

Hampus changed the status from Under consideration to Answered 7m ago

History

2 comments

Pierre OP1 vote 35m ago

RUST Code Example : use std::sync::mpsc; use std::thread; use std::time::Duration; fn main() { // Communication channel (Tx = Transmitter, Rx = Receiver) let (tx, rx) = mpsc::channel(); // Spawn a background "process" (thread) thread::spawn(move || { // Simulate a task or event to transmit thread::sleep(Duration::from_millis(100)); tx.send("Ping: Data transmitted via IPC!").unwrap(); }); // Receive the message in the main process let message = rx.recv().unwrap(); println!("Received -> {}", message); }

Permalink

HampusStaff 1 vote 7m ago

This isn't a correct read of the codebase. There are no WebContentsViews to suspend. Desktop creates a main BrowserWindow, with account switching inside the shared application. Background accounts already use gateway sessions and snapshots. There are no separate hidden account interfaces.

Permalink