dtourolleandClaude Opus 5
3330f350a4
Build and test / Desktop (Linux) (push) Failing after 1m1s
Build and test / Layer separation (push) Successful in 24s
Traceability / Requirement traces (push) Successful in 22s
🐳 Android image / Build and push (push) Successful in 1s
Build and test / android-image (push) Successful in 1s
Build and test / Android (aarch64) (push) Failing after 22m19s
The last of the per-scroll queries, and the strangest of them: this one got slower the further down the library you had scrolled. The marker has to follow every scroll event or it advances in jerks while the photographs beside it move smoothly — that part is right and stays. What was wrong is that each event asked the catalog `LIMIT 1 OFFSET n`, and that is not a seek: SQLite reaches row `n` by producing and discarding the `n` rows before it. 0.02 ms near the top of the library, 0.7 ms at twenty thousand, per row crossed, on the thread drawing the frame. A flick therefore got choppier the longer it went on. The window the grid has already read holds the answer, and since the loaded window now covers the whole view, the row is nearly always in it. So this is a vector index at the position the ordinal has in the window, and the query survives only as the fallback for a row outside it — briefly, after a scrub or a keyboard jump, before the load lands. The fallback is also the less correct of the two, which is worth recording rather than quietly keeping: it counts in a dated-only ordering while the argument is a grid row, so the two disagree wherever undated frames sit in between. It is kept because a marker about to be corrected is not worth a second index, and because being wrong there is what it always did. The window path has no such disagreement — it reads the very cell the row belongs to. 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 |
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.