Repository navigation
webxr: disable the decoder warm-up timeouts by default - #1383
Conversation
A CloudXR runtime with no OpenXR app streams idle frames that count as decoder warm-up frames, so the 10 s begin and 30 s end deadlines can tear down a healthy session that is only waiting for an app to start. Default warmupBeginTimeoutMs and warmupEndTimeoutMs to 0, which disables the detection; callers and the URL/OOB parameters can still set a deadline. Stream-attach detection is unchanged. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Signed-off-by: Gareth Morgan <gmorgan@nvidia.com>
|
No actionable comments were generated in the recent review.
|
|
✅ Preview deployed: https://NVIDIA.github.io/IsaacCapture/preview/pr-1383/client/ Built from commit fae20e8. It may take a minute for the updated preview to appear. |
There was a problem hiding this comment.
To confirm my understanding, I assume we're going to re-enable these timeouts once we have changes from Cloudxr.js?
Yes, this is for 1.6.0 |
Summary
warmupBeginTimeoutMsandwarmupEndTimeoutMsto 0, which disables decoder warm-up detection (since fix(webxr): let 0 disable the stream-attach and warm-up timeouts #1257). The defaults change in the component, the client's default configuration, and the two settings inputs and their labels.Validation
npm testpasses (134 tests); the mock tests pass explicit warm-up timeouts, so they don't depend on the defaults. eslint and prettier are clean, and pre-commit passes.setTimeoutand fires immediately instead of disabling.🤖 Generated with Claude Code
Summary by CodeRabbit