Skip to content

fix(wgc): make the GPU encode path opt-in until it earns the default - #337

Merged
EtienneLescot merged 2 commits into
mainfrom
fix/dxgi-opt-in
Aug 11, 2026
Merged

fix(wgc): make the GPU encode path opt-in until it earns the default#337
EtienneLescot merged 2 commits into
mainfrom
fix/dxgi-opt-in

Conversation

@EtienneLescot

@EtienneLescot EtienneLescot commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

One line, plus the docs that described the old default.

-    readEnvInt("OPENSCREEN_WGC_DISABLE_DXGI_INPUT", 0) == 0;
+    readEnvInt("OPENSCREEN_WGC_ENABLE_DXGI_INPUT", 0) == 1 && …

Why

The GPU path has one confirmed success and one confirmed regression:

#252 display and window capture went from a 13 s hang to a 105 ms stop
#336 recording ends outright, for the same person who reported #327, who had working video before

Its fallbacks cover every check inside initialize(). Nothing covers a failure that only appears once frames are flowing — which is what #336 is: the pipeline comes up, the sink writer is configured for NV12, and then a per-frame call fails with nowhere left to fall back to.

Defaulting it on makes every user carry that risk so the few who reproduce #252 might not have to — and nobody has confirmed it fixes #252.

What this is not

Not a revert. The path, its six review fixes, the writerMutex_ lock-order split, the stop breadcrumbs and the adapter reporting all stay. They are either independent of this default, or they exist to diagnose the bug the path was written for. The one line is the whole change: the code was fine, the confidence behind switching it on for everyone was not.

Earning the default back

Either of:

  1. A failure mid-encode degrades to the CPU path instead of ending the recording
  2. Someone on hardware that reproduces [Bug]: v1.8.0 native Windows recorder still hangs on stop; next attempt says capture is not running #252 confirms it fixes them, with OPENSCREEN_WGC_ENABLE_DXGI_INPUT=1

Needs cherry-picking onto release/v1.9.4 before the next RC.

Summary by CodeRabbit

  • New Features
    • Added an opt-in Windows GPU video-input path using OPENSCREEN_WGC_ENABLE_DXGI_INPUT=1.
    • GPU capture can fall back to CPU readback during initialization when needed.
  • Bug Fixes
    • Improved compatibility by keeping software encoding and inline webcam picture-in-picture recordings on supported capture paths.
    • Separate webcam output remains eligible for GPU capture.
    • Recording now stops if GPU capture fails after initialization.
  • Documentation
    • Updated Windows recording documentation to describe opt-in behavior and measured variable-bitrate performance.

It has one confirmed success and one confirmed regression. On the machine in
#252 it took display and window capture from a 13-second hang to a 105 ms stop.
On the machine in #336 -- the same person who reported #327 -- it ended
recording outright, where the CPU path had been producing video.

Its fallbacks cover every check made inside initialize(). Nothing covers a
failure that only shows up once frames are flowing, which is exactly what #336
is: the pipeline comes up, the sink writer is configured for NV12, and then a
per-frame call fails with nowhere left to fall back to.

Defaulting it on makes every user carry that risk so that the few who reproduce
#252 might not have to, and #252 is not confirmed fixed by anyone. So: off, and
OPENSCREEN_WGC_ENABLE_DXGI_INPUT=1 turns it on, which is what the people in
#252 and #327 should be given to test with.

Nothing is reverted. The path, its six review fixes, the writerMutex_ lock-order
split, the stop breadcrumbs and the adapter reporting all stay -- they are
either independent of this default or exist to diagnose the bug it was written
for. The one line is the whole change, which is the point: the code was fine,
the confidence behind switching it on for everyone was not.

Earning the default back means one of two things: a failure mid-encode degrades
to the CPU path instead of ending the recording, or someone on the affected
hardware confirms it fixes #252.
@coderabbitai

coderabbitai Bot commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 11a27afc-401b-4af9-955b-bfbd3787451e

📥 Commits

Reviewing files that changed from the base of the PR and between 68e7fe5 and fbc81a0.

📒 Files selected for processing (1)
  • technical-documentation/architecture/recording.md

📝 Walkthrough

Walkthrough

Windows WGC DXGI input is now disabled by default and enabled with OPENSCREEN_WGC_ENABLE_DXGI_INPUT=1. Software encoding and inline webcam PiP remain excluded. Documentation describes CPU fallback during initialization and post-start GPU failure behavior.

Changes

Windows DXGI input configuration

Layer / File(s) Summary
DXGI input selection and fallback documentation
electron/native/wgc-capture/src/main.cpp, electron/native/README.md, technical-documentation/architecture/recording.md
DXGI input now requires OPENSCREEN_WGC_ENABLE_DXGI_INPUT=1. Software encoding and inline webcam PiP remain excluded. Initialization failures can fall back to CPU readback, while post-start GPU sample failures stop recording. The previous disable variable was removed.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Description check ⚠️ Warning The description explains the rationale and scope but omits the required Related issue, Type, Release impact, Desktop impact, and Testing sections. Add the required template sections, identify the related issue with Refs #252, record Windows and release impact, and describe validation performed.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly identifies the WGC GPU encode path change and its new opt-in default.
Linked Issues check ✅ Passed The PR mitigates #252 by disabling the risky GPU input path by default while retaining an opt-in path for validation and future fixes.
Out of Scope Changes check ✅ Passed All code and documentation changes directly implement the opt-in GPU path default and document the new behavior.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/dxgi-opt-in

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@technical-documentation/architecture/recording.md`:
- Line 72: Update the architecture description around the video writer paths to
state that GPU input is runtime-opt-in via OPENSCREEN_WGC_ENABLE_DXGI_INPUT=1,
while hardware determines whether initialization selects DXGI or CPU. Replace
the claim that GPU input falls back at every step with wording that limits
fallback to initialization; preserve that captureDxgiSample() failures after
encoding starts stop the recording.
🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 80267acf-413a-45aa-a05b-5effb8af77f7

📥 Commits

Reviewing files that changed from the base of the PR and between be6e883 and 68e7fe5.

📒 Files selected for processing (3)
  • electron/native/README.md
  • electron/native/wgc-capture/src/main.cpp
  • technical-documentation/architecture/recording.md

Comment thread technical-documentation/architecture/recording.md Outdated
Two clauses survived the default flip and both said the opposite of the change.
"which one runs is a per-machine outcome, not a setting" was true before the
env var gated it. "degrades to the CPU one on its own at every step" was never
true after the first frame -- which is the entire reason the default moved --
and it sat two sentences from a note saying so.

Now says it plainly: the fallback is initialization-only, it ends when frames
start, and that is the gap #336 fell into.
@EtienneLescot
EtienneLescot merged commit 4f9d74a into main Aug 11, 2026
14 of 15 checks passed
@EtienneLescot
EtienneLescot deleted the fix/dxgi-opt-in branch August 11, 2026 07:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: v1.8.0 native Windows recorder still hangs on stop; next attempt says capture is not running

1 participant