dtourolleandClaude Opus 5
772a69711d
FR-DSP-5 has been satisfied for some time and untagged. `Framing::view` shrinks the sampled region while the render target keeps its size, so a zoom raises the resolution the pipeline works at rather than magnifying pixels already drawn — there is no second full-resolution path because the zoom is that path. Tagging it on that basis alone is what §7 of the display spec warns against: traceability counts a requirement as covered when a comment names it, and checks nothing about the code under the tag. So the tag goes on tests instead, and the tests are built so that removing the behaviour breaks them. Both failure modes were checked by hand: deleting the view from `visible_rect` leaves the 1:1 render flat, and dropping only its offset leaves the render exactly inverted. The assertion message names both, since those are the two ways this can go wrong and the numbers alone do not say which. The fixture is one-pixel black-and-white stripes — the highest frequency an image can hold, and precisely what a proxy discards. A 1024 px source in a 128 px viewport reads source column `8x + 4` for every output column `x`, all the same parity, so the fit render comes out uniform; that is asserted first, because a 1:1 render showing detail proves nothing unless the proxy is known to carry none. What remains is an equality against the source bytes rather than a claim that something looks sharper. The third test takes the arbitrary zoom the requirement also names, and pins `RenderScale` beside the pixels: a zoom that moved the pixels but not the scale would sharpen at the wrong radius, which stays invisible until somebody compares a preview against an export. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
DarkRoom
A cross-platform, non-destructive RAW photo editor for Linux and Android.
Status: early. v0.1 is a remote library viewer — see docs/milestone-v0.1.md.
Documentation
| Document | Contents |
|---|---|
| requirements.md | What the software must do — 122 numbered requirements |
| architecture.md | How it is built — crates, GPU pipeline, data model, sync |
| milestone-v0.1.md | The first buildable milestone |
| faces.md | Face detection and identity — the models, the licence problem, and what S14 measures |
Building
Desktop:
cargo run -p darkroom-desktop
Android (containerised toolchain, see docker/android):
./docker/android/build.sh cargo ndk -t arm64-v8a build --release
Current state
Working: workspace, GPU context and compute pass, adaptive Slint shell, Android cross-compilation of the core crates.
Not yet working: the zero-copy display path. The build currently uploads frames through the CPU, which is exactly what ARCH §6.1 forbids — measured at 96% of frame time at 4K. Replacing it is spike S1, the project's highest priority.
cargo run -p dr-gpu --example bench --features readback
reproduces that measurement.
Licence
GPL-3.0-or-later.