Why StackWM 1.4.2 Feels Faster Everywhere

StackWM 1.4.2 is labeled as a patch release. The contrast appears when you use it quickly or keep it running all day.

Before 1.4.2, StackWM could complete the right action and still feel wrong. A window reached the zone you chose, then an older task rewrote its mapping. Focus landed on the correct window, then a timed-out activation pulled it back. The correct action happened first; obsolete work followed it.

In 1.4.2, the final request owns activation, geometry, and mapping. When a newer action starts, older work loses permission to touch that window.

There is no new “turbo mode” and no benchmark-friendly trick. The app feels faster because it does less work after your intent has already changed.

TL;DR

Rapid Push and focus commands now follow one rule: the latest request wins.
Superseded activation work stops instead of continuing to raise or focus an old window.
Push activation no longer performs synchronous sleeps on the main thread.
Detached windows and vanished zones release their Accessibility references instead of accumulating stale work.
Scene restore uses the correct display coordinates on vertically arranged monitors, and old migrations no longer repeat unnecessary decoding at every launch.
You can install 1.4.2 over your current version. No settings reset or layout rebuild is required.

Before and after: the short version

Situation	Before 1.4.2	In 1.4.2	What you notice
Rapid Push	A delayed reconcile could restore an older zone mapping after the window had moved	A new Push invalidates the previous owner before geometry starts	The final zone stays final, and the next command starts from the right state
Rapid focus or cycle	A timed-out activation could continue raising the previous window	Cancellation and generation checks stop every superseded activation	Focus does not bounce back after you release the shortcut
Input path	Cycle gestures could perform Accessibility work inside the event callback, while Push activation slept on the main thread	Event callbacks only hit-test in memory; activation continues asynchronously	Repeated shortcuts are less likely to pause behind an older request
Long-running session	Detached window references could remain retained, and hotkey refresh could unregister the same reference twice	Window references are released consistently and each hotkey has one owner	Less stale state remains after apps, windows, and layouts change
Scenes and stacked displays	Conflicting coordinate formulas could choose the wrong display, while a broken marker repeated old migration work	One coordinate boundary and valid migration markers take the direct path	Scene restore needs less correction and finished migrations stay finished

The comparison is not “the same task took 100 ms before and 60 ms now.” It is “the right task ran, then an obsolete task interfered” versus “only the final intent is allowed to finish.”

Smoothness was a correctness problem

A window command is not one operation. StackWM has to identify the window, activate its app, request a new size and position through the macOS Accessibility API, wait for the physical window to settle, and then commit the new zone mapping.

That sequence is asynchronous. If you press another shortcut before the first sequence finishes, two requests can overlap.

The slow feeling often did not come from expensive computation. It came from an older request waking up late and doing valid work for an invalid goal. A stale activation could raise the previous window. A delayed Push reconciliation could restore the previous zone mapping. StackWM would then spend more time correcting state that should never have changed again.

Version 1.4.2 removes that conflict at the ownership level.

1. The latest Push owns the result

Consider moving a terminal from Zone 4 to Zone 3 in quick succession. The physical window may already arrive in Zone 3 while a delayed reconciliation from the Zone 4 request is still waiting for macOS to expose a stable window ID.

Previously, that older reconciliation could wake up and write Zone 4 back into StackWM’s internal mapping. The window looked correct for a moment, but the next shortcut started from stale state. That is the kind of bug that feels like lag, a snap-back, or a command that needs to be pressed twice.

Every Push now claims ownership of its target window before geometry work begins. A newer Push replaces the old ownership token immediately. When an older task resumes, it checks the token and exits without touching the mapping.

Visible result: when several Push commands overlap, the last command remains authoritative. There is no late internal rewind after the window has already moved.

2. Old focus requests now stop

Focus switching had a similar problem. A timed-out activation request was cancelled, but some waits inside that request ignored cancellation. The old task could continue issuing raise, main-window, and focused-window writes while a newer request was already running.

That produced focus flapping: the correct window appeared, then an older window stole focus back.

In 1.4.2, every activation request receives a generation token. Cancellation-aware waits stop promptly, and StackWM checks ownership again before each Accessibility write. A superseded request cannot fall back to a broader window search and cannot compete with the latest request.

Push activation also moved off the synchronous path that previously included three main-thread sleeps. Scroll-wheel cycle gestures now do only an in-memory hit test inside the event-tap callback, then move Accessibility work onto the main run loop. The hotkey listener spends less time blocked by macOS inter-process calls.

Visible result: rapid cycling stops on the window you chose, and input handling is less likely to pause behind an old activation attempt.

3. Long sessions carry less baggage

Performance after several hours is often a state-management problem rather than a launch-time problem.

StackWM keeps references to managed macOS windows so it can cycle, restore, and move them without rediscovering everything. Those references must be released when a window detaches or when its zone disappears. Some cleanup paths updated the zone mapping but retained the old Accessibility element, allowing stale window references to accumulate as apps and layouts changed.

Version 1.4.2 makes detach and layout resync release those references consistently. It also validates a destination zone before changing the window mapping, so a failed attach cannot leave half-written state behind.

Dynamic region hotkeys received the same treatment. Each Carbon hotkey reference now has one owner, so a refresh no longer tries to unregister the same reference twice.

This is not a dramatic benchmark number at launch. It is the quieter improvement you notice after opening and closing apps, changing layouts, sleeping the Mac, and continuing to work: StackWM has less stale state to inspect and less cleanup to repeat.

4. Multi-display and Scene work takes the direct path

macOS exposes window geometry in more than one coordinate system. StackWM previously carried several screen-flip formulas, including one that used the combined height of every display. That formula breaks when a monitor sits above the primary display or is taller than it.

All CG, Accessibility, and AppKit conversions now use the primary display’s global origin as the single flip axis. Scene save and restore convert window frames at the system boundary before choosing a display.

Legacy Scene migrations were also corrected. One completion marker pointed at a directory that did not exist, so StackWM could repeat a full Scene decode on every launch. Another migration used the wrong date-decoding strategy and silently skipped layout-reference updates. Both now use the same paths and encoding rules as the live Scene store.

Visible result: vertically arranged displays restore more reliably, and startup no longer repeats migration work that already finished.

Removing code is not the performance claim

This release also removed roughly 1,600 lines of dead migration, layout, hotkey, and UI code. That makes StackWM easier to maintain, but dead code does not consume runtime by itself.

The actual performance improvement comes from the live paths that were simplified: fewer synchronous waits, fewer Accessibility calls inside event callbacks, cancellation that really cancels, one owner for each operation, and cleanup that releases old window state.

That distinction matters. “Less code” is useful engineering. “Less obsolete work while you are pressing shortcuts” is what makes the app feel faster.

Compare it yourself in three minutes

After installing 1.4.2, you can verify the difference without changing your layout:

Push one window across several zones quickly. The old failure pattern was “arrive correctly, then start the next command from an older zone.” In 1.4.2, the final location remains the source of truth.
Cycle focus rapidly, then release the shortcut. The old failure pattern was a late bounce to the previous window. In 1.4.2, focus remains on the last selection.
Repeat both actions after a long session. Open and close several app windows, switch Scenes, sleep and wake the Mac, then try again. The comparison to watch is whether responsiveness changes as stale state accumulates; 1.4.2 now releases that state on detach and layout resync.
If your displays are vertically arranged, save and restore a Scene. The old failure pattern was a wrong-display placement followed by correction. In 1.4.2, windows should return directly to the intended display.

If your apps already responded instantly and you never issued overlapping commands, the change may feel subtle. The biggest difference appears in the exact moments that previously felt inconsistent: fast repeated input, apps restarting, delayed Accessibility responses, display changes, and long-running sessions.

What 1.4.2 does not change

StackWM still works through the macOS Accessibility API. Some apps animate window changes, impose minimum sizes, or expose their window ID late. StackWM cannot make those apps respond faster than they allow.

What it can do is avoid making the delay worse. It waits for the physical window state, accepts legitimate app constraints, and prevents old operations from repairing, focusing, or remapping a window after a newer operation has taken ownership.

That is the theme of 1.4.2: less fighting, less correction, and a more direct path from shortcut to final window state.

Update to StackWM 1.4.2

StackWM 1.4.2 is available now for macOS 15.6 and later. The update is notarized by Apple and can be installed over your existing version without resetting Scenes, layouts, or hotkeys.

Download StackWM 1.4.2 or read the complete release notes.

Author: StackWM Team. Building predictable macOS workspaces since 2025. Last updated: 2026-08-06