dtourolle
49b7bc2f9d
Each sync pass spent 0.8-2.0 s of CPU and 1.0-5.4 s wall on the upload snapshot of the reference catalog (24k images, 18,871 faces), ahead of the rest of the pass. The upload itself had been crop-less since the crops moved to the face shards. The cost was in how it got that way. The backup API copied all 158 MB of the catalog, 96 MB of it the ~5 KB JPEG crop on every faces row. Then `UPDATE faces SET crop = NULL` rewrote 18.9k rows and freed their overflow chains, and VACUUM rebuilt the file again. That wrote the catalog about three times over to upload 50 MB. The snapshot is now built rather than copied. An empty file attaches the catalog, creates each table from the catalog's own sqlite_master and fills it with INSERT ... SELECT, with faces.crop selected as NULL. Indexes, triggers and views follow, and user_version, application_id, page size and the WAL header flag are carried over. It all runs in one transaction on the snapshot's connection, so the catalog is read as of one moment and concurrent writers are serialised, not raced, as the backup API did. The build journal is in memory with synchronous off, because the file is scratch that is rebuilt every pass and quick_check'd before upload. Foreign keys are off on that connection. The bundled SQLite enables them, and then a multi-row INSERT into images scans images for children of each new row (shadowed_by is a self-reference with no index), which cost 1.2 s alone. Measured on a .backup copy of the reference catalog with catalog_bench, old and new binaries back to back on a loaded machine: before best 1.0-5.4 s wall, 0.84-1.98 s cpu, 49.8 MB after best 0.40-2.1 s wall, 0.39-0.96 s cpu, 50.4 MB With the machine quiet the new build takes 0.31-0.43 s. What a receiving device gets is unchanged. It is the same schema, the same rows and a NULL crop, which is what 0.16.0 already uploads and merges. The merge reads only a remote face's box and model (merge::match_faces) and never writes a local crop. No device adopts a downloaded catalog as its own, and a fresh one takes faces and crops from the shards. There is no schema bump, so older builds still merge it. NFR-R2 backups keep using the backup API and keep their crops. Tests: the snapshot matches the catalog in schema, row counts, pragmas and WAL header. A leftover file is replaced. Merging a crop-less snapshot carries a confirmed name across by box and leaves the local crop untouched, and does so idempotently.
Documentation
Two audiences, two folders. Most people want the first table and never the second.
Using DarkRoom
| The manual | Every feature, pictured from the application itself — opening a library, rating, labelling and filing, duplicate originals, developing, local masks, repair, film, panoramas, export. The application carries it and opens it from Help and from Settings |
| How it is driven | Every gesture and shortcut, by screen. Generated from the code, so it cannot describe one the application does not have. The same list is the in-app help sheet: Help or F1 in the grid, ? or F1 in develop |
The top-level README says what DarkRoom is, how to get it on each platform, and what is still missing.
Changing DarkRoom
Everything under dev/ is for someone working on the code. Start with
CONTRIBUTING.md, which says how to land a first change
without reading the rest.
The register and the record. What must be built, how it is built, and how far along it is.
| requirements.md | What the software must do — the numbered register, the decisions (D-numbers) and the spikes (S-numbers) |
| architecture.md | How it is built — crates, the GPU pipeline, the data model, sync |
| traceability.md | Generated: which requirement is claimed by which file. Never edited by hand |
| outstanding.md | What is specified and not built, and whether that is a decision or a gap |
| technical-debt.md | Compromises taken deliberately, each with the condition that retires it |
| code-health.md | What a contribution costs, per seam, measured |
Designs, one per subsystem. Each is the specification the code was built to, kept current as the code moved.
| catalog.md | The index, the library view, incremental scan, the job queue |
| storage.md | Storage backends: the seam a folder, a sync client and a Nextcloud account share |
| faces.md | Face detection, identity, clustering and the eye-state models |
| segmentation.md | How the application finds the regions a local mask snaps to |
| mask-editing.md | Painting, erasing and combining masks |
| spot-removal.md | Clone and heal as parameters in the edit graph |
| panorama.md | Alignment, projection, the chunked composite and the border fill |
| inference.md | The neural runtime and model chosen per device, with the measurements |
| display-and-extension.md | The display contract, and why the fused pipeline is already most of a plugin format |
| view-composition.md | A controller for the display layer |
| ui-navigation.md | Finding things in the interface once there are many |
Measurements. Numbers committed so a regression is a diff rather than a recollection.
| benchmarks.md | The per-commit suite: what it covers, what it does not, how to read a failure |
| bench-baseline.json | The committed numbers the suite checks against |
| frame-budget.md | What a frame costs on each device, and the decision those figures settled |
Platforms and distribution.
| distribution.md | Which channels v1 targets and what each one constrains |
| windows.md | The Windows installer, cross-built from the Linux CI |
| android-signing.md | Which key signs the APK, and keeping it |
Archive. Kept as the record of what was asked for, not as plans.
| milestone-v0.1.md | The first milestone, delivered 2026-08-30 and superseded |
| ui-refinement.md | How the interface should look; succeeded by ui-navigation.md |
Conventions
Three files here are generated and must not be edited by hand:
gestures.md, dev/traceability.md and manual/index.html, the page the
packages install, rendered from manual/README.md. All three come from
cargo run -p traceability, the pre-commit hook keeps them in step with the
tree, and CI fails when one is not what the tree generates. The manual's
pictures are recorded by tools/manual and live
in LFS.
A design document links to the requirements it satisfies and to the code
that satisfies them. When the code moves, the link moves with it; a document
that has stopped being true goes to dev/archive/ with a note saying what
replaced it, rather than being deleted.