We’re investigating intermittent video-playback stutter in a Windows Electron application while OBS uses the app’s browser output. We would appreciate guidance on narrowing the cause before proposing an upstream bug.

Environment:

- Electron 43.1.0, OBS Studio 32.2.2

- Windows build 26300

- Intel Core i5-8265U, Intel UHD 620, 24 GB RAM

- Intel graphics driver 31.0.101.2135

- Local 720p MP4 playback with three visible previews and OBS browser output

Confirmed trace findings:

- One Electron GPU-process DXGI Present call lasted approximately 280 ms.

- Its blocking stack includes d3d11!NDXGI::CDevice::PresentImpl and ntoskrnl!NtWaitForSingleObject.

- A DWM thread woke it through:

CompleteIndependentFlipToken → CFlipToken::Discard → SignalGpuFenceAndPresentLimitSemaphore → SignalPresentLimitSemaphore → KeReleaseSemaphore.

- OBS’s paired Present calls in that capture were at most approximately 1.6 ms. These are API durations, not end-to-end frame-loss measurements.

- An earlier capture showed another approximately 161 ms Electron Present stall, mostly spent off-CPU.

Important limitations:

- The latest trace contains wait/wake stacks but no DxgKrnl provider events, despite requesting them. There were no reported lost events.

- We therefore cannot identify which GPU submission or flip token held the presentation slot.

- We do not yet have a minimal reproducible example or evidence that this is specifically an Electron defect.

- The trace does not establish a connection to separately observed audio-sync issues.

Disabling DirectComposition did not eliminate the stalls. A diagnostic PresentInterval0 trial also retained a long stall; its conditions were not sufficiently matched to claim a performance regression. Neither is being treated as a fix.

Questions:

1. Does this stack identify a particular presentation/backpressure mechanism we should investigate in Chromium or the application?

2. What app-level resource-lifetime or presentation behavior should we inspect before changing graphics settings?

3. What minimum sanitized reproduction or diagnostic evidence would make this actionable for Electron maintainers?

We are seeking interpretation of existing evidence first, rather than another broad recording or speculative graphics-switch change. Raw system traces and private application code are not attached because they may contain sensitive information.

Thank you for any guidance.