Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Screenshots take ~1.6s on 6K: grim uses default PNG compression (-l 6)
Reported by phuclh · filed Sep 3, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
What happened
omarchy capture screenshot takes ~1.6 seconds to save a full-screen capture on a 6K display. The delay is not the screen capture — it is grim running at its default PNG compression level (6).
omarchy-capture-screenshot invokes grim with no -l flag in all three code paths:
65: grim -g "$SELECTION" "$FILEPATH" || exit 1
76: grim -g "$SELECTION" - | wl-copy --type image/png
79: grim -g "$SELECTION" "$FILEPATH" || exit 1grim(1) defaults to -l 6. At 6144x3456 (21.2 MPix) zlib dominates total runtime.
Measurements
Display: LG UltraFine 6K, [email protected], scale 2. 3 runs each, median:
| Command | Time | Size |
|---|---|---|
grim -t ppm (capture only, no encode) | 127 ms | 61 MB |
grim -l 1 | 564 ms | 8.2 MB |
grim -l 4 | 746 ms | 6.9 MB |
grim (current behaviour, -l 6) | 1628 ms | 6.4 MB |
Capture costs 127 ms. The remaining ~1500 ms is PNG compression. -l 1 is 2.9x faster for ~28% more bytes.
The effect scales with pixel count, so it is proportionally milder at 1080p but still present:
| 1920x1080 region | Time | Size |
|---|---|---|
grim -l 6 | 495 ms | 1.8 MB |
grim -l 1 | 223 ms | 2.3 MB |
Expected
A screenshot should feel immediate. Spending ~1.5 s of CPU to save ~1.8 MB is a poor trade for a transient screenshot, especially on the HiDPI displays where Omarchy is most likely to be used.
Steps to reproduce
- Attach a 4K or higher display.
time grim /tmp/a.pngtime grim -l 1 /tmp/b.png- Compare. The gap widens with resolution.
Suggested fix
Pass a lower compression level in omarchy-capture-screenshot:
- grim -g "$SELECTION" "$FILEPATH" || exit 1
+ grim -l 1 -g "$SELECTION" "$FILEPATH" || exit 1-l 1 gives the largest win; -l 4 is a middle ground (746 ms, 6.9 MB) if file size matters more. Applying it to the wl-copy path matters most, since a clipboard image is discarded almost immediately and its compression ratio is irrelevant.
Unrelated note
omarchy-capture-region uses a fixed sleep .1 after starting the hyprpicker freeze. On this machine the hyprpicker layer registers in ~7 ms, so the 100 ms is mostly dead time. Minor next to the above, but it is on the same path.
System
- Omarchy 4.0.2-1
- CPU: Intel Core 5 320
- GPU: Intel Wildcat Lake
[8086:fd80](xe) - Hyprland 0.56.2
- grim 1.5.0-2
- Display: LG UltraFine 6K, 6144x3456@60, scale 2
View raw text
### What happened `omarchy capture screenshot` takes **~1.6 seconds** to save a full-screen capture on a 6K display. The delay is not the screen capture — it is `grim` running at its default PNG compression level (6). `omarchy-capture-screenshot` invokes `grim` with no `-l` flag in all three code paths: ``` 65: grim -g "$SELECTION" "$FILEPATH" || exit 1 76: grim -g "$SELECTION" - | wl-copy --type image/png 79: grim -g "$SELECTION" "$FILEPATH" || exit 1 ``` grim(1) defaults to `-l 6`. At 6144x3456 (21.2 MPix) zlib dominates total runtime. ### Measurements Display: LG UltraFine 6K, `[email protected]`, scale 2. 3 runs each, median: | Command | Time | Size | |---|---|---| | `grim -t ppm` (capture only, no encode) | **127 ms** | 61 MB | | `grim -l 1` | **564 ms** | 8.2 MB | | `grim -l 4` | 746 ms | 6.9 MB | | `grim` (current behaviour, `-l 6`) | **1628 ms** | 6.4 MB | Capture costs 127 ms. The remaining ~1500 ms is PNG compression. `-l 1` is **2.9x faster** for ~28% more bytes. The effect scales with pixel count, so it is proportionally milder at 1080p but still present: | 1920x1080 region | Time | Size | |---|---|---| | `grim -l 6` | 495 ms | 1.8 MB | | `grim -l 1` | 223 ms | 2.3 MB | ### Expected A screenshot should feel immediate. Spending ~1.5 s of CPU to save ~1.8 MB is a poor trade for a transient screenshot, especially on the HiDPI displays where Omarchy is most likely to be used. ### Steps to reproduce 1. Attach a 4K or higher display. 2. `time grim /tmp/a.png` 3. `time grim -l 1 /tmp/b.png` 4. Compare. The gap widens with resolution. ### Suggested fix Pass a lower compression level in `omarchy-capture-screenshot`: ```diff - grim -g "$SELECTION" "$FILEPATH" || exit 1 + grim -l 1 -g "$SELECTION" "$FILEPATH" || exit 1 ``` `-l 1` gives the largest win; `-l 4` is a middle ground (746 ms, 6.9 MB) if file size matters more. Applying it to the `wl-copy` path matters most, since a clipboard image is discarded almost immediately and its compression ratio is irrelevant. ### Unrelated note `omarchy-capture-region` uses a fixed `sleep .1` after starting the `hyprpicker` freeze. On this machine the hyprpicker layer registers in ~7 ms, so the 100 ms is mostly dead time. Minor next to the above, but it is on the same path. ### System - Omarchy 4.0.2-1 - CPU: Intel Core 5 320 - GPU: Intel Wildcat Lake `[8086:fd80]` (xe) - Hyprland 0.56.2 - grim 1.5.0-2 - Display: LG UltraFine 6K, 6144x3456@60, scale 2
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 10:41 UTC