[botandbang]

What and why

When a track gets within its warning time of the end (30 s by default), only the time left starts blinking, which is easy to miss while you're on the mixer. Now the track's overview waveform also washes twice in the warning colour as the warning starts, 720 ms in all, then the blink carries on as before.

• Transitions::follow_warning is told each frame whether the warning is on (end_style) and where the overview was drawn (areas.overview, the deck's or the strip's, empty when neither is). A wash starts each time the warning comes on, and stops if it goes off first, so seeking back out and in again starts another.
• step_wash runs two 360 ms pulses: in 24-bit colour each cell's text colour blends into the warning colour and back; in 256 and 16 colours it snaps to the tier's warning colour (the scheme's red in 16) at the height of each pulse and back.
• Nothing washes with LOCALLIBRARY_REDUCED_MOTION, without colours, or in a test's app. The wash keeps no heap memory of its own, and while it runs the player keeps its quick frame rate, as for a fade.
• docs/player.md says so.

It doesn't use tachyonfx, so it doesn't depend on fades running in 256 colours.

Fixes LOC-262

How it was tested

• the_end_warning_washes_once_a_crossing: the wash comes on with the warning, is fully the warning colour at the height of the first pulse and back between pulses, stops after two, doesn't start again while the warning stays on, and starts again after the warning goes off and on.
• the_wash_snaps_in_16_colours_and_needs_motion: in 16 colours it snaps at the height of a pulse; with less motion, or in a test's app, none starts.
• prop_the_end_warning_washes_from_each_crossing (Hegel) checks over any run of frames that a wash starts only as the warning comes on, stops when it goes off or after two pulses, and only ever changes colours inside the overview, never a symbol.
• With a wash started every frame the warning is on, the first and third fail; with less motion ignored, the second and third do.
• The 157 tui::transitions, frames, ui and deck tests pass, as do cargo fmt --check, cargo clippy --workspace --all-targets, the same with --no-default-features and for x86_64-pc-windows-gnu, and cargo doc with -D warnings. The frame budget test's frames run with transitions off, as before, so benchmarks/budgets/tui.json is unchanged.

Checklist

• Tests cover the change
• For locallibrary: apps/locallibrary/changes/loc-262-end-warning-wash.md has a changelog line
• The READMEs, docs/ and --help still say what the code does

diagrams-checked: apps/locallibrary/docs/diagrams/player.md#player-views: ui.rs only starts a wash of the overview as the end warning comes on; the views and how a frame is drawn are the same
diagrams-checked: apps/locallibrary/docs/diagrams/player.md#deck-layout: the deck's overview washes as the end warning comes on; the layout is the same

[linear-code]

LOC-262

[github-actions]

Size

Compared with main. KiB are 1,024 bytes.

	This pull request	main	Change
Client JavaScript	858.9 KiB	858.9 KiB	0 B (0%)
Client JavaScript, brotli	294.7 KiB	294.7 KiB	0 B (0%)
Client CSS	97.6 KiB	97.6 KiB	0 B (0%)
Client CSS, brotli	14.4 KiB	14.4 KiB	0 B (0%)

[github-actions]

Rust coverage

From run 930. Both are held to the thresholds in .cargo/config.toml.

Tests	Lines	Functions	Regions
All	98.12% (93071/94856)	97.64% (15272/15641)	96.79% (206452/213291)
Hegel property tests alone	97.17% (92167/94856)	96.62% (15113/15641)	95.68% (204074/213291)