dtourolleandClaude Opus 5
8155f5276e
Two families were the weak points: FR-DSP at 37%, which is the architecture's central performance claim, and FR-PLG at zero. They are one document because the same property decides both — the pipeline composes its work from declarations, which is why the display path is fast and is also, already, most of a plugin format. Two findings change the size of the job. **Some of FR-DSP is done and untagged.** Zoom already meets FR-DSP-5: the sampled region shrinks while the render target keeps its size, so zooming raises the resolution the pipeline works at — arrived at without tiles. **FR-DSP-2 may not be worth satisfying as written.** It predates the fused shader and assumes a chain of passes over a large buffer, where recomputing per frame is ruinous and tiles are the way out. What exists composes every active operation into one dispatch over a viewport-sized target. So the spec fixes three measurements and a decision rule *in advance*: if a frame sits inside budget at the 99th percentile, the requirement is rewritten rather than implemented, and tiling becomes what it actually is here — a scheduling concern for export, which already runs off the frame path. Writing a tile scheduler the design does not need would be the most expensive way to find that out. **The plugin format already exists**, resolved at build time: `ops/*.yaml` through `build.rs` produces something indistinguishable from a hand-written operation, and everything it produces is data plus a WGSL string. The blocker is one line — `descriptor()` returns `&'static` — and the rest is an interpreter over declarations, load-time WGSL validation, and namespaced ids, because the sidecar stores parameters by id and a collision is a wrong edit silently applied. Recorded last and deliberately: traceability counts a tag, not a behaviour. `FR-DEV-8` is tagged against plumbing a future spot-removal op would use and `FR-DEV-7` against a history row for a frontend that does not exist, so 51% is an overstatement of unknown size. Every requirement this plan closes should be closed by a test that fails if the behaviour is removed. Co-Authored-By: Claude Opus 5 (1M context) <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.