dtourolle
a3f3e188e1
Benchmarks / CPU and I/O (per commit) (push) Successful in 1m52s
Benchmarks / Frame budget (on demand) (push) Skipped
Build and test / Desktop (Linux) (push) Successful in 45m4s
Build and test / Layer separation (push) Successful in 41s
Traceability / Requirement traces (push) Successful in 29s
🐳 Android image / Build and push (push) Successful in 1s
Build and test / android-image (push) Successful in 2s
🐳 Windows image / Build and push (push) Successful in 1s
Build and test / windows-image (push) Successful in 1s
Build and test / Android (aarch64) (push) Successful in 29m25s
Build and test / Windows (x86_64, cross) (push) Successful in 34m4s
Build and test / Publish the release (push) Skipped
Filtering the grid by a face crawled on the reference library. The SQL is not it — the person predicate counts in ~20 ms, the eyes-open term in ~60 — but every press on the tray ran `push_people_chips`, which read the whole people table (26,362 rows, nearly all empty groups a regrouping pass left behind) and then called `push_people_roster`, which read it again and replaced the roster model. The roster is every person holding a face, 1,581 chips, in a row Slint does not virtualise: a new model tore down and re-created all of them and laid the row out again, to move one tick. A press now walks the roster model and sets `picked` on the rows whose tick changed; the roster is built only when the tray opens. Both reads use `people_in_use` (2,140 rows) rather than `people`. A picked person the in-use query leaves out — emptied by a split while the filter held them — still gets a chip, since a term with no chip cannot be removed, and without one the in-place update would fall back to a rebuild on every press.