← All issues

Introduce SharedTimebase and stop sending time updates every 100ms

1feeb18

WebKit's multi-process model puts media decoding in the GPU process and JS in the WebContent process; every video.currentTime query must answer synchronously without an IPC round-trip. Previously the GPU sent MediaTimeUpdateData anchors ~4×/sec; TimeProgressEstimator cached and extrapolated. The new SharedTimebase maps a small SharedMemory region into both processes — GPU holds the writer, WebContent holds the SharedTimebaseReader, and reads are lock-free via SequenceLocked<T> (a seqlock).

Source/WebCore/platform/SharedTimebase.h (new)

+struct Snapshot {
+ MediaTime currentTime;
+ double playbackRate;
+ MonotonicTime hostTime;
+};
+class SharedTimebase : public RefCounted<SharedTimebase> { ... };

Source/WebKit/WebProcess/GPU/media/AudioVideoRendererRemote.cpp

- TimeProgressEstimator m_timeEstimator;
+ std::unique_ptr<SharedTimebaseReader> m_sharedTimebaseReader;
+ std::optional<MediaTime> m_stallCap;

In the same commit: AVFoundation's 0→nonzero rate-lie is masked at source with a fine-grained time observer, and the stall cap moves from the deleted TimeProgressEstimator inner class onto AudioVideoRendererRemote itself under m_lock.

Eliminates steady-state IPC noise for every active media element and introduces a new cross-process shared-memory surface that the WebContent process reads without IPC message validation — a meaningful trust-boundary shift on top of the performance win.

🔒

New cross-process shared-memory path with lock-free reads and conditional stall-cap logic — several edge cases across the trust boundary are worth security investigation.

Subscribe to read more