Skip to content

Bound surface reconfiguration retries - #461

Closed
jackwalkerlabs wants to merge 1 commit into
parasyte:mainfrom
jackwalkerlabs:fix/bound-surface-retry
Closed

Bound surface reconfiguration retries#461
jackwalkerlabs wants to merge 1 commit into
parasyte:mainfrom
jackwalkerlabs:fix/bound-surface-retry

Conversation

@jackwalkerlabs

Copy link
Copy Markdown

Closes #460.

A persistent Suboptimal, Outdated, or Lost result currently reconfigures the surface and re-enters an unconditional loop. If reconfiguration cannot correct the status—such as while the cached size is stale—render_with never returns and the event loop cannot deliver the resize that would recover it.

This restores the bounded behavior from before the wgpu 29 update:

  • reconfigure and retry acquisition once;
  • return Error::Surface if a recoverable status persists;
  • retain the existing skip behavior for Occluded/Timeout and validation error handling;
  • regression-test that only one reconfiguration is performed before returning the error.

Validation:

  • cargo fmt --all -- --check
  • cargo check --workspace
  • cargo doc --workspace --no-deps
  • cargo clippy --workspace --tests -- -D warnings
  • cargo test --workspace
  • CI-equivalent WASM and Android cargo check/Clippy commands for all three cross targets
  • git diff --check

The Linux/X11 driver hang is not available on this macOS host; the source-level failure is deterministic, and the regression exercises the bounded recovery policy without requiring a real GPU surface.

@parasyte

parasyte commented Aug 4, 2026

Copy link
Copy Markdown
Owner

Thanks. I opened #462 with my preferred fix to the unbounded loop problem.

@jackwalkerlabs

Copy link
Copy Markdown
Author

Thanks for taking this over. #462 covers the bounded behavior with the implementation you prefer, so I am closing this one.

parasyte added a commit that referenced this pull request Aug 12, 2026
This will turn the infinite loop into an error. It does not address
the cause of the infinite loop. Users who experience the hang will
instead need to handle the error appropriately instead of
terminating the application.

The root cause was identified in #460 as a permenant
desynchonization between the window manager's understanding of the
window size and `pixels`' understanding of the surface size. Making
`pixels` robust to this desync is currently out of scope, as it
will require a major refactor.

Closes #460
Closes #461
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.

render() can loop forever reconfiguring the surface when the cached surface size is stale

2 participants