----------------------------------------------------
SECTION 1 — Summary of the Issue
VDMX may show the following symptoms on macOS 26.2 (Tahoe):
- Slow startup (20–40 seconds)
- Output window not staying on top
- Lag or stuttering when another window overlaps the output window
- UI sluggishness
- Window ordering inconsistencies
These issues are NOT caused by:
- GPU load
- Metal fallback
- CoreAnimation failures
- OpenGL compatibility issues
- Compositor throttling
All graphics subsystems appear healthy.
The root cause is macOS 26’s stricter handling of SecureTextInput.
SECTION 2 — Root Cause
macOS 26 introduced a change in the SkyLight window manager:
When SecureTextInput is active, macOS blocks applications from raising windows or changing window levels unless the action is directly triggered by the user.
SecureTextInput is activated by:
- Spotlight search
- Save/Open dialogs
- Finder rename fields
- Notes or any NSTextField
- Safari URL bar
- Password fields
- Autofill scanning for sensitive fields
VDMX relies heavily on:
- Custom window levels
- Always‑on‑top output windows
- Programmatic window ordering
When SecureTextInput is active, macOS denies these operations. This causes:
- Slow startup (VDMX repeatedly tries to set window levels)
- Output window failing to stay on top
- Lag when overlapping windows
- UI stuttering
- WindowServer “deferring events” spam
This behavior did not occur in earlier macOS versions.
SECTION 3 — Key WindowServer Log Evidence
Example log lines confirming the issue:
“CPS: Denying VDMX6 Plus the right to be in front because secureTextInput is active and this process doesn’t have secure text mode enabled, and this request was not caused by user activity”
“Deferring events from frontmost process…”
These appear repeatedly during VDMX startup and window creation.
No GPU or compositor errors appear.
SECTION 4 — Why Text Fields Cause Lag
When a text field is focused:
- macOS enables SecureTextInput
- macOS blocks VDMX from raising its output window
- VDMX continues trying to reorder the window
- WindowServer defers focus and ordering events
- The compositor stalls
- Visible lag occurs in the output window
Dragging a save dialog or rename window over the VDMX output window reliably triggers this.
SECTION 5 — Why Autofill Made It Worse
Autofill can activate SecureTextInput in the background while scanning for password fields.
Disabling Autofill reduces the frequency of the issue.
SECTION 6 — Reproducible Test Case
- Open Spotlight or any text field.
- Launch VDMX.
- Observe slow startup.
- Drag a save dialog or rename window over the VDMX output window.
- Lag and window ordering issues appear.
- Close Spotlight and relaunch VDMX.
- Behavior disappears.
SECTION 7 — Workarounds for Users
- Disable Autofill
- Close Spotlight before launching VDMX
- Avoid having text fields active during performance
- Launch VDMX immediately after login for a clean input state
- Use a second display for the output window
- Avoid Safari password fields or URL bar during shows
- Avoid Finder rename fields during shows
- Avoid renaming or inputing text in any box even inside vdmx when running a live show for now
SECTION 8 — Developer‑Focused Notes (for VIDVOX)
WindowServer denies window‑ordering requests when SecureTextInput is active.
VDMX attempts to set window levels and bring windows forward during startup. These calls are blocked unless user‑initiated.
Graphics subsystems show no errors.
Recommendations:
- Consider explicitly requesting secure text mode during window‑ordering operations
- Delay window‑level changes until SecureTextInput is inactive
- Provide a fallback window‑ordering path when CPS denies SetFrontProcess
- File a report with Apple referencing the CPS denial logs
