bread-screenshots: 5 s grim timeout truncates 4K captures under load and leaves a partial PNG #63

New issue

Closed

opened 2026-10-01 16:24:15 +08:00 by Breadway · 1 comment

Breadway commented

2026-10-01 16:24:15 +08:00

Owner

What

bread-screenshots gives grim a hard 5 second limit (GRIM_TIMEOUT in bread-screenshots/src/lib.rs). On a 3840x2160 output (headless Sway at scale 2) under CPU load, encoding the PNG takes longer than that. grim is killed mid-write, the app reports grim failed for geometry 0,0 1920x1080: with an empty reason, and a truncated PNG is left at the output path.

Impact

Captures of the heavier views fail (breadbar stage-results, stage-calc, surtitle, surtitle-critical in testing). Light views still pass, so the failure looks view-specific when it is really timing.
The leftover file has a valid PNG header, so anything that only checks that the file exists, or reads just the header (ImageMagick identify, for example), treats it as a good capture. In one bread-capture run the truncated files sat next to the good ones with nothing marking them as broken.

How it was found

Capturing breadbar main's spotlight views at 4K for the BOS trailer while another session was compiling Rust (load average around 7). The four views failed every time. With the timeout raised to 30 s in a private build, all four captured cleanly on the first try.

Confidence

High for the cause: the same views pass once the timeout is raised. Medium on the exact threshold, since it depends on machine load and output size.

Suggested fix

Raise the timeout, or scale it with output pixel count, or let the caller override it.
On timeout or failure, delete the partial output file.
Give the error a reason, such as "grim timed out after Ns".

## What `bread-screenshots` gives `grim` a hard 5 second limit (`GRIM_TIMEOUT` in `bread-screenshots/src/lib.rs`). On a 3840x2160 output (headless Sway at scale 2) under CPU load, encoding the PNG takes longer than that. `grim` is killed mid-write, the app reports `grim failed for geometry 0,0 1920x1080:` with an empty reason, and a **truncated PNG is left at the output path**. ## Impact - Captures of the heavier views fail (breadbar `stage-results`, `stage-calc`, `surtitle`, `surtitle-critical` in testing). Light views still pass, so the failure looks view-specific when it is really timing. - The leftover file has a valid PNG header, so anything that only checks that the file exists, or reads just the header (ImageMagick `identify`, for example), treats it as a good capture. In one bread-capture run the truncated files sat next to the good ones with nothing marking them as broken. ## How it was found Capturing breadbar main's spotlight views at 4K for the BOS trailer while another session was compiling Rust (load average around 7). The four views failed every time. With the timeout raised to 30 s in a private build, all four captured cleanly on the first try. ## Confidence High for the cause: the same views pass once the timeout is raised. Medium on the exact threshold, since it depends on machine load and output size. ## Suggested fix - Raise the timeout, or scale it with output pixel count, or let the caller override it. - On timeout or failure, delete the partial output file. - Give the error a reason, such as "grim timed out after Ns".

Breadway added the

bug

label

2026-10-01 16:24:15 +08:00

Breadway referenced this issue from a pull request that will close it,

2026-10-01 16:49:58 +08:00

fix(screenshots): clean up timed out captures #64

Breadway commented

2026-10-01 17:46:56 +08:00

Author

Owner

Implementation is available in PR #64 at f9ea59975bcca94d94ea72bcfa27b67bce2fcaa6. Local checks passed: cargo test --offline -p bread-utils -p bread-screenshots and Clippy. Exact-head CI is pending and waiting to run; if it fails, move this item back to TODO.

Implementation is available in PR #64 at `f9ea59975bcca94d94ea72bcfa27b67bce2fcaa6`. Local checks passed: cargo test --offline -p bread-utils -p bread-screenshots and Clippy. Exact-head CI is pending and waiting to run; if it fails, move this item back to TODO.

Breadway closed this issue

2026-10-02 12:06:38 +08:00