When GPU-accelerated rendering fails on Linux, the app starts and shows nothing. The window exists, the process is alive, and the user has a blank rectangle with no message and no way back. The AppImage libwayland-client fix (#525) removed one cause; it did not make the class of failure survivable.
Shape
A sentinel written before the window is created and cleared once the interface has actually painted. A launch that finds the sentinel still there knows the previous one never got that far, and starts in software rendering instead — with an explanation, because a silent downgrade is its own kind of confusing.
Plus an escape hatch: an environment variable to force gpu / software / auto, so a user who has been told what to try can try it without editing anything.
Why this is cheaper than it looks
The signal already exists. lib.rs emits app://ready when the frontend has painted — the splash handoff already depends on it. That is exactly the "we got far enough" event the sentinel needs to clear on, so no new instrumentation is required.
The trap to write down before starting
A WebKit process crash must block the disarming, not just a failure to start. If the sentinel is cleared on window close as well as on paint, then the user closing the blank window clears the evidence, and the next launch tries the GPU path again — the loop repeats forever and the mechanism appears not to work. The sentinel is cleared by paint and by nothing else.
Worth considering alongside: a known-bad environment check, so a platform we already know cannot do GPU rendering starts in software on the first run rather than the second.
When GPU-accelerated rendering fails on Linux, the app starts and shows nothing. The window exists, the process is alive, and the user has a blank rectangle with no message and no way back. The AppImage
libwayland-clientfix (#525) removed one cause; it did not make the class of failure survivable.Shape
A sentinel written before the window is created and cleared once the interface has actually painted. A launch that finds the sentinel still there knows the previous one never got that far, and starts in software rendering instead — with an explanation, because a silent downgrade is its own kind of confusing.
Plus an escape hatch: an environment variable to force
gpu/software/auto, so a user who has been told what to try can try it without editing anything.Why this is cheaper than it looks
The signal already exists.
lib.rsemitsapp://readywhen the frontend has painted — the splash handoff already depends on it. That is exactly the "we got far enough" event the sentinel needs to clear on, so no new instrumentation is required.The trap to write down before starting
A WebKit process crash must block the disarming, not just a failure to start. If the sentinel is cleared on window close as well as on paint, then the user closing the blank window clears the evidence, and the next launch tries the GPU path again — the loop repeats forever and the mechanism appears not to work. The sentinel is cleared by paint and by nothing else.
Worth considering alongside: a known-bad environment check, so a platform we already know cannot do GPU rendering starts in software on the first run rather than the second.