Crystallize and Pointillize performance

Measured on 2026-10-15, against 4e7a17cd5d5723313f459753663d0d155f047e19. The code revision is 3a527eb64e0d0108e44c70dfd200afc0ffd5fe67.

Whole command

The command bench calls Session::execute on a populated 6000 x 4000 RGB layer. The table below uses 16 workers and 8-bit storage. The clock includes filtering and the history commit. It excludes document setup, GUI repaint and presentation. The last run also checks that Undo restores the source and Redo restores the filtered result. Both checks happen outside the clock.

Ordinary layers are unlocked and have varying alpha, including zero alpha. Background layers are opaque and transparency-locked. The existing transparency restoration pass limits their speedup, especially Pointillize at small cell sizes. These are command timings, not input-to-display timings.

Whole filter

The filter bench times apply_in: reading the input, filtering, converting the result back to the document depth, writing the tiles and pruning. The table below uses 16 workers. There is no selection in these timing cases. Correctness tests also cover soft selections. The fixture has varying alpha, fully transparent pixels and a negative origin. Every run filters the original surface again; no result cache survives a run.

All trials and output hashes are in pixelate-cell-timings.json. Filter hashes are SHA-256 of the complete tile-ordered normalized f32 output. Command hashes are BLAKE3 of the complete tile-ordered native storage bytes. Fixture generation, output dumps and hashing are outside the measured interval.

Where the time went

Both filters were rebuilding the seeded cell geometry for every pixel and every neighbour. Pointillize also repeated the dot radius, source lookup and colour jitter. Those values belong to the cell. The new grid prepares them once per cell in a tile, reducing that setup work from roughly nine times the pixel count to the number of cells.

Crystallize accumulated a premultiplied average for every cell, then usually threw it away and used the pixel at the cell centre. Only cells whose centres are outside the image need that average. The new path skips interior averages. Boundary cells still add their samples in the original row order, with the original f32 rounding.

Larger cells also allow whole horizontal spans to share a winner. For each site, the absolute horizontal distance has its maximum at an endpoint. Clamping the site centre to the span gives a lower bound. The rounded coordinate map is monotone; squaring nonnegative distances, adding the fixed vertical term and taking a square root preserve these bounds through the same f32 operations. Subtracting distance from a fixed dot radius reverses the endpoints for Pointillize. If one site's worst score beats every other site's best score, it owns the span. Otherwise the span splits. Single pixels retain the original strict comparison and tie order. A fully covered Pointillize span also has exactly unit coverage, so it needs no per-pixel square roots.

The tile path reads sparse cell-centre samples directly from the surface. Crystallize's boundary tiles retain the dense input for their averages. Extent clamping and selection mixing follow the original path.

After these changes, profiling showed a serial tail: converting samples and writing them back took about 160-180 ms of a roughly 260 ms operation. The two filters now convert on their existing tile workers. Committing a group copies encoded bytes. Integer rounding and native byte order are the same as Surface::write_region; float bits are kept. The optional site grid is capped at 16 MiB. Failed grid/average reservations use the scalar kernel; a failed encode reservation keeps the existing floating-point writeback.

Reproduce

Machine: EC2 c7i.4xlarge, 16 vCPUs (8 cores with SMT), 32 GiB RAM, Intel Xeon Platinum 8488C, Ubuntu 24.04, rustc 1.99.0. Release profile, thin LTO, one codegen unit. No target-cpu override. Five trials per row; tables use the median. One-worker rows are in the raw results too. Before and after use separate target directories so Cargo cannot reuse a library from the other worktree. No builds ran during the timed trials.

RAYON_NUM_THREADS=16 cargo run --release -p picto-algo --example bench_pixelate -- crystallize 6000 4000 u8 5 /tmp/crystallize.bin rgb
RAYON_NUM_THREADS=16 cargo run --release -p picto-algo --example bench_pixelate -- pointillize-large 6000 4000 u16 5 /tmp/pointillize.bin cmyk
RAYON_NUM_THREADS=16 cargo run --release -p picto-engine --example bench_cell_filters -- crystallize 10 5 8 layer
RAYON_NUM_THREADS=16 cargo run --release -p picto-engine --example bench_cell_filters -- pointillize 100 5 8 layer
RAYON_NUM_THREADS=16 cargo run --release -p picto-engine --example bench_cell_filters -- pointillize 5 5 8 background

For the before run, create a worktree at the base above and copy the two benchmark examples into it. Build with a separate CARGO_TARGET_DIR and run there with the same arguments and thread count. The -large filter cases use cell size 100; the other cases use 10 for Crystallize and 5 for Pointillize. The engine example takes the size explicitly.

Validation

• 2,447 tests passed across algo and engine; 43 ignored.
• Clippy passed for both crates with all targets and warnings denied.
• Layer checks, wasm checks, scorecard freshness and the quick performance suite passed.
• Scalar comparisons cover RGB, Gray, CMYK, Lab and Multichannel, alpha on/off, negative origins, fractional cells, boundary averages, HDR and nonfinite samples.
• Storage comparisons cover U8/U16/F32, soft selections, clamped extents and several tile sizes. The span tests compare discrete winners and coverage, including coordinates near f32 precision boundaries.
• All 44 measured before/after configurations have identical output hashes. The 16 command configurations also pass Undo/Redo checks.