Do not panic when device().poll() times out

[jcuffney]

Both wgpu window renderers ended render by unwrapping the completion poll:

render_surface
    .device()
    .poll(wgpu::PollType::wait_indefinitely())
    .unwrap();

If the driver never signals the submission complete, that returns
Err(PollError::Timeout) and the unwrap aborts the process.

This drops the error instead. The frame has already been presented by the time
the poll runs — the call waits for GPU completion rather than producing output —
so there is nothing to retry and nothing to skip. It also makes the line
consistent with the check six lines above it in the same function, which already
degrades:

if render_surface.maybe_blit_and_present().is_err() {
    return;
}

Same class as #38 ("Fix Timeout crash when getting surface texture") and #46
("Handle transient WGPU SurfaceErrors without panicking"), both merged. The
reasoning in #46 applies unchanged: some of these errors are transient, and the
right response is to carry on rather than bring down the whole process.

Two choices I made on your behalf — happy to change either

Not logging it. Neither crate has a logging dependency, and the only
tracing::warn! in either is commented out at the analogous "unexpected state"
site in resume. Adding tracing for this seemed like the wrong trade to make
uninvited, but say the word.

An ## [Unreleased] section. No API change, so this is ### Fixed at patch
level. Neither changelog had an Unreleased section yet — that is the Keep a
Changelog convention, but if you would rather these were added at release time I
will drop them. The entries reference this PR by number.

How I hit it

A Pixel 10 (PowerVR D-Series), release build, via dioxus-native 0.8.0-alpha.1
→ anyrender_vello_hybrid 0.8.0 and anyrender_vello 0.12.0. Both crates fail
identically at the identical line. The app survives roughly 2 launches in 8;
the survivors render correctly and stay up, so the scene and the pipeline are
fine — the driver just does not always finish the submission.

The driver behaviour is not yours to fix and I am not asking for a workaround
for it. But a GPU stall producing an abort() rather than a dropped frame is
the difference between a janky app and one that will not launch.

(Debug builds on the same device die earlier and for an unrelated reason: the
PowerVR SPIR-V compiler aborts in spvcompiler::LLVMDIWriter::Init because wgpu
turns InstanceFlags::DEBUG on in debug builds. WGPU_DEBUG=0 avoids that one.
Mentioning it only so this is not confused with it.)

Related

#67 proposes a real FrameOutcome result from WindowRenderer::render, which
would let a host decide what to do here. This is the three-line version, and I
would be glad to see #67 supersede it.

Checks

cargo check and cargo fmt --all --check pass on both crates. MSRV
unaffected — no new syntax, no new dependency.

Related

The reason I needed the CPU renderer at all is DioxusLabs/dioxus#5849: the
vello-cpu-* and skia arms of dioxus-native cannot be selected by any
consumer, so on this device there was no working renderer of any kind. That one
is independent of this change - either fix helps on its own.

---

🤖 Generated with Claude Code