6 Commits

Include renames

Author	SHA1	Message	Date
dtourolleandClaude Opus 5	cf8f5b632f	Show the develop frame itself, instead of a photocopy of it ... The oldest open item in the project (ARCH §6.1, spike S1, AC-8). Every frame in develop was read off the GPU into a `SharedPixelBuffer` and handed back to Slint to upload again: ~7 ms at 4K against a 0.28 ms compute pass, 96% of the frame spent carrying pixels to the CPU and back so they could be drawn where they already were. Slint 1.17 will adopt a `wgpu::Texture` directly, and the whole of what that needs is arrangement rather than code. **One device, made before the window.** A texture belongs to the device that allocated it, so the compute passes and the compositor cannot each open their own. `GpuContext::new_shared` opens one and hands back the instance and adapter alongside it; `dr_ui::shared_gpu` gives all four to `BackendSelector::require_wgpu_29(WGPUConfiguration::Manual { .. })`. That call has to come before the first window, because creating one selects a backend for you — which is why the GPU is now opened at the top of `run` rather than two hundred lines down beside the other controllers. dr-gpu still names no UI type. It hands out raw wgpu and does not ask who is compositing (ARCH §6.5a). **Vulkan only on the shared path**, where headless keeps its GL fallback. wgpu's GL backend reaches its display through EGL at instance creation, and before a window exists there is no display handle to give it — so a GL instance cannot later produce the window surface Slint needs from it. A machine with no Vulkan gets no shared device and browses without develop, which is the same degradation as no adapter at all. **`renderer-femtovg` becomes `renderer-femtovg-wgpu`.** The old one is FemtoVG over OpenGL and cannot be handed a wgpu texture at all. It is not kept alongside as a fallback: FemtoVG-over-GL has no branch for an imported texture, falls through to "render this image into a buffer", gets nothing, and draws nothing — a blank canvas with no error, which is worse than the failure it would be papering over. The consequence is stated plainly in the manifest: the desktop app now needs a working wgpu adapter to open a window. **Two output textures, not one, and this is the part that is not obvious.** Slint repaints when the image property *changes*, and it decides that with `PartialEq` — which for two images over the same `wgpu::Texture` says "unchanged". A pass that reused a single target would have rendered every slider move correctly on the GPU and shown none of them: right, and invisible. `AdjustPass` alternates between two targets, so consecutive frames are genuinely different values. It also settles the read-while-write question that one queue was already answering. `RENDER_ATTACHMENT` is added to both render targets. Neither pass uses it; Slint rejects an imported texture without it, on the reasoning that a compositor handed a texture may need to draw into it. **`AdjustPass::read_output` is deleted rather than gated.** It and `export_pixels` were the same transfer under two names, and the comments explaining why they were separate are the point of the whole criterion: reading pixels back to *display* them is the defect, reading them back to *encode a file* is the only way a file is made. The display twin is now gone outright, which is stronger than a feature flag — it cannot be turned back on. `export_pixels` is untouched and still ungated. The `readback` feature comes off dr-ui, darkroom-desktop and darkroom-android; it stays in dr-gpu, where it still gates `RenderTarget::read_pixels` and the segmentation field readback. `examples/develop` moves to `export_pixels`, which is honest — it writes a PPM — and so no longer needs the feature. Four tests, each named for what it protects and each of which fails without a screen if the property it guards breaks: - the adjust target satisfies every condition Slint's import checks, asserted in the crate that owns the descriptor, because a descriptor that drifts fails at runtime on a real display and nothing else would notice; - consecutive renders are different textures, and the third is the first again, so the alternation is a rotation and not an allocation per frame; - the develop canvas has no CPU pixel buffer and does have a wgpu texture — AC-8 itself, in the terms Slint uses; - consecutive frames compare unequal as `slint::Image`, which is the property the repaint actually depends on. The zoom test's readback moves into the test module. It has to: there is no library function that copies a displayed frame to the CPU any more, and that is the point — the round-trip now exists in the test binary and nowhere a shipping build can reach. **What is not proven.** No GUI was run. What is verified is that the texture satisfies the import contract, that the import succeeds, that the canvas is a texture rather than a buffer, and that consecutive frames are distinguishable. What is unverified is everything that needs a display: that Slint's FemtoVG wgpu renderer adopts the Manual configuration on a real surface, that the picture appears the right way up and the right colour, and the frame timing that motivated the whole exercise. Android is untouched by testing — the android backend routes a WGPU29 request to Skia, whose wgpu surface does handle imported textures, but that is read from the source, not observed. 56 dr-gpu tests and 255 dr-ui tests pass, clippy clean under `-D warnings`, fmt clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 09:54:00 +02:00
dtourolleandClaude Opus 5	d7aeafaf84	Move to wgpu 29, the version Slint can share a device with ... Groundwork for spike S1. Importing a texture into a Slint scene requires it to come from the *same* `wgpu::Device` Slint renders with, and Slint hands out a device of the version it was compiled against. Slint 1.17 offers `unstable-wgpu-28` and `unstable-wgpu-29` and nothing older, so wgpu 23 could never have met it: two semver-incompatible wgpu crates in one tree are two distinct types, and the device would not typecheck across the gap. The version is therefore not a free choice, and the manifest now says so — Slint and wgpu move together or not at all. The Slint requirement is also corrected from "1.9" to the 1.17 it has actually been resolving to. Nothing about the render path changes here. The readback bridge is still in place and still the display path, so this is verified by the tests that already existed rather than by anything new: 39 dr-gpu tests, which compare real pixels off a real device, and 888 across the workspace, all passing. Zero-copy lands separately and small. What the six releases cost, in full: - `ImageCopyTexture`/`ImageCopyBuffer`/`ImageDataLayout` became the `TexelCopy*` names (24). - `Instance::new` takes the descriptor by value, and `InstanceDescriptor` lost its `Default` — it carries a boxed display handle now, so a headless context says `new_without_display_handle` and means it. - `request_adapter` returns `Result` rather than `Option` (24). - `DeviceDescriptor` absorbed the API trace from `request_device`'s second argument and gained `experimental_features` (25). - `PipelineLayoutDescriptor` takes `Option<&BindGroupLayout>` per slot, and `push_constant_ranges` became `immediate_size`. - `Maintain` became `PollType`, and `poll` is fallible. Two of those are improvements worth having rather than churn. The error scope is a guard whose `pop` runs on drop, so an early return from the pipeline compiler no longer leaves a scope open on the device for whatever ran next to fall into. And a fallible `poll` reports a lost device (NFR-R7) at the point it happens, where before the map callback simply never arrived and the failure surfaced later as a readback that spun out its poll limit. Still to do for S1: dr-ui renders through `renderer-femtovg`, which is OpenGL. Texture import needs Slint itself rendering on wgpu. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 21:34:04 +02:00
dtourolleandClaude Opus 5	7c57f490fe	Declare a develop operation in YAML, and generate the rest ... An operation was, in the overwhelming majority of cases, four facts: what its parameters are, what uniforms they compute, what WGSL those uniforms drive, and where it sits in the chain. Written in Rust those four facts arrived wrapped in ninety lines of trait implementation — a match on parameter id to a struct field, another match back, an is_active comparing each field to its default, a Vec<Uniform> built by hand. All mechanical, and each one a place to make a silent mistake: a param() arm returning the wrong field reads perfectly and breaks the sidecar round-trip. So the four facts are the file now. core/dr-pipeline/ops/<id>.yaml is a node, build.rs compiles it into the same Operation impl as before, and the result lands in OUT_DIR — the same reasoning as style.yaml -> theme.slint, including why it does not land beside the sources it would look exactly like. Nothing downstream can tell a declared node from a hand-written one: same &'static OpDescriptor, same fused-shader composition, same sidecar. Nine nodes moved: exposure, white_balance, contrast, highlights_shadows, blacks_whites, brilliance, vibrance, saturation, and the shared WGSL helper registry. Their prose came with them, and so did their tests — set/expect/expect_active/expect_wgsl in the declaration compile to real #[test]s, so a node file carries its own proof rather than leaving it behind in a file that no longer exists. Two stayed in Rust and say so with `rust:`. The tone curve's neutral is a relationship between five interpolated points rather than a set of values; the colour mixer generates thirty-six faceted parameters from twelve computed hue bands. A schema stretched to cover either would be a worse language than Rust aimed at one caller. They still declare their position here, because the chain's *order* is the one thing a reader comes to this directory to learn, and an order written half in YAML and half in Rust would be worse than either alone. default_chain() is generated from it. Uniforms are derived by a small expression language — exp2(exposure), blacks / 100 * 0.02 — compiled to Rust rather than interpreted, so an unknown name or a wrong arity is a build error naming the file and the key and the arithmetic costs nothing at runtime. The build script refuses a duplicate order, a filename disagreeing with its id, a default outside its own range, a test value the graph would clamp before the node saw it, a helper that does not define the function it names, and a declared node colliding with a file in src/ops. Verified by adding a scratch node and removing it again: one file, no other edit, and it joined the chain at its declared order with its test running. 237 tests pass in dr-pipeline, clippy and fmt clean. .yaml joins the traceability tool's scanned suffixes, because a node's Rust now lives in OUT_DIR where a tag could never be linked from the report. Coverage 47.7% -> 48.3%. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 21:08:16 +02:00
dtourolle	2ca1716a29	Make "Choose folder" an actual folder picker ... It previously fetched the folder list and threw it away into a status line — a button that looked like it worked and did not. Now it opens a browsable picker: click a folder to descend, ".." to go back, "Use this folder" to select, "Cancel" to leave the root unchanged. Descends one level per click because that is what the backend supports: Depth: infinity is frequently disabled server-side and prohibitively expensive where it is not (ARCH §8.4). The chosen root persists immediately on confirm, so it survives a crash before the library is opened. Confirming at the account root is allowed — a user may legitimately keep everything at the top level — and cancelling leaves any previous selection untouched, which a test asserts. Verified against nextcloud.tourolle.paris at both depths: 30 folders at the root, 21 year-folders inside PhotosRaw. 19 launch tests, 38 in dr-ui.	2026-08-09 15:50:40 +02:00
dtourolle	09e3043f4c	Add secure credential storage, sessions, and a launch screen ... Login now persists properly rather than through the JSON file the test harness was using. dr-plat SecretStore trait plus a Secret Service backend. Verified against the live GNOME Keyring: store, retrieve, delete, confirm-gone all round-trip. Session/SessionStore splits credentials from settings — the app password goes to the keyring (FR-NC-2), while server, login, chosen root and format selection are ordinary config. A test asserts the credential never appears in the config file. LaunchModel the launch-screen state machine, testable without a display server: sign in, approve in browser, choose folder, tick formats, sign out. launch.slint the screen itself, in its own file. Absence of a secrets daemon is an explicit degraded mode, not a silent fallback to plaintext — the screen says sign-in will not persist rather than letting the user find out next launch. Android's Keystore backend fails loudly for the same reason: a no-op store would look like it worked and then lose the credential. Two bugs caught by tests rather than by running it: - fail() after busy() signed the user out, because busy() had already discarded the session. A failed *scan* would have logged you out. Busy now carries the session. - normalise_server upgrades http:// to https:// rather than accepting it. NFR-SEC-3 requires TLS, and silently sending a credential in the clear is not a decision to make on the user's behalf. launch.slint is not yet wired into app.slint. Calling slint_build::compile twice replaces the generated module rather than adding to it, which broke the other in-flight work on dr-ui; I reverted that immediately. Wiring it needs an import inside app.slint, which is that work's file to change. 419 tests passing across ten crates.	2026-08-09 15:20:39 +02:00
dtourolleandClaude Opus 5	78e3e6b846	Add the develop pipeline: demosaic and seven raw adjustments ... Decode through display, on the GPU: black/white normalisation, Bayer demosaic, camera colour transform, and the first seven adjustment operations — white balance, exposure, highlights/shadows, blacks/whites, brilliance, vibrance, saturation. Composable shaders. Each operation contributes a WGSL fragment rather than owning a pass, and dr-pipeline fuses the *active* ones into a single compute shader. One texture read and one write per frame regardless of how many adjustments are in play, while the operations stay independent in Rust — adding one is a new file, with no central shader to edit. An operation at neutral settings contributes no code, no uniform and no branch. Uniforms are prefixed per operation so two may both declare `amount`; helpers dedupe by name from a single source of truth. Pipelines cache on a structure hash covering the op-set and its order but not the values, so dragging a slider uploads uniforms and reuses the compiled pipeline. Measured on a 24 MP CR2: 0.60 ms re-render, one pipeline compiled across ten slider positions. The UI is generated, not written. EditGraph::capabilities() reports parameters with their kinds, ranges, defaults and current values; the panel builds one control per entry chosen by ParamKind. No file in ui/ names an operation, and dr-pipeline has no wgpu dependency, so codegen is testable without a device (ARCH §6.5a). Three defects found against real files, each silent: - rawler 0.7.2's `xyz_to_cam` is all zeros — deprecated and no longer populated. The live matrices are in `color_matrix`, keyed by illuminant. Reading the old field yields no colour transform at all. - `cam_to_xyz_normalized()` returns all NaN on any Bayer sensor: it divides each of four rows by its own sum, and the unused fourth (emerald) row sums to zero. Inverting the 3x3 ourselves avoids it. `wb_coeffs[3]` is NaN for the same reason and is normalised at decode. - As-shot white balance reached the uniform block but no shader read it, so the first render of a real CR2 came out violently green. Green photosites collect roughly twice the signal of red and blue. Now applied unconditionally before any operation, with tests on ordering. Demosaic is Malvar-He-Cutler rather than bilinear: gradient-corrected interpolation at one 5x5 neighbourhood per pixel, where bilinear leaves visible zippering on any high-contrast edge at 1:1. Two of the four packed CFA constants were wrong on the first attempt, so all four layouts are asserted to reconstruct the same colour. Crop origins at odd coordinates re-phase the pattern; without that, red and blue swap. X-Trans reports GpuError::UnsupportedCfa rather than approximating with the Bayer path, which would look like a corrupt file. 206 tests, including GPU tests proving every operation and the full seven-operation chain generate compilable WGSL. Known gaps: the display path still reads back to the CPU each frame, which ARCH §6.1 forbids and AC-8 asserts against — it is gated behind the `readback` feature and waits on spike S1 wiring Slint's texture import. Curve shapes are a first draft and want tuning against real photographs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-09 11:37:58 +02:00