How Live Desktop Wallpapers Work on macOS — No Dedicated GPU Required

Matrix Desktop uses Apple Silicon's integrated GPU and a Metal compute pipeline to render film-accurate digital rain. It needs no discrete GPU and automatically reduces frame rate and effects on battery or under thermal pressure.

What is a desktop-level window?

A live wallpaper is a regular NSWindow placed at the desktop window level. macOS has a strict window layering system, and each level has a numeric z-order. The desktop level sits below every other window, including Finder icons, app windows, and the menu bar.

Copy// Place the window behind all other content
window.level = NSWindow.Level(
    rawValue: Int(CGWindowLevelForKey(.desktopWindow))
)
window.collectionBehavior = [.canJoinAllSpaces, .stationary]
window.isOpaque = true
window.hasShadow = false

That is the layering trick. The window renders behind other content, ignores mouse events, and stays out of normal app switching. macOS composites it as a desktop-level surface.

What this is NOT

• Not a screensaver. Screensavers activate after idle time and take over the entire display. A desktop-level window runs continuously behind your work.
• Not a video loop. Video playback decodes compressed frames on the media engine, which is efficient but inflexible. Matrix Desktop generates every frame procedurally, so the rain is never repetitive and responds to parameter changes in real time.
• Not an Electron app. There is no Chromium process or JavaScript runtime. The current native AppKit and Metal download is 2.3 MB.

Metal compute shaders vs. traditional rendering

The rendering pipeline does not use Metal's traditional vertex/fragment shader pipeline. Instead, it uses compute shaders exclusively. Compute shaders write directly to textures without going through rasterization, which is more efficient for full-screen image processing.

Copy// Each pass dispatches a 2D grid over the output texture
let threadgroupSize = MTLSize(width: 16, height: 16, depth: 1)
let threadgroups = MTLSize(
    width: (textureWidth + 15) / 16,
    height: (textureHeight + 15) / 16,
    depth: 1
)
encoder.dispatchThreadgroups(threadgroups, threadsPerThreadgroup: threadgroupSize)

The key advantage of compute pipelines: they run on any Metal-capable GPU. There is no requirement for dedicated VRAM, discrete graphics hardware, or specific GPU features. Every Mac sold since 2012 supports Metal, and every Apple Silicon chip has a GPU that runs compute shaders natively.

The 5-pass pipeline

Each pass reads from one texture and writes to another. The GPU processes pixels in parallel, and the amount of work scales with the drawable's pixel dimensions.

Why Apple Silicon fits this pipeline

Apple Silicon uses unified memory architecture (UMA), so the CPU and integrated GPU share one memory system. Matrix Desktop writes compact simulation state into Metal-managed buffers and lets Metal synchronize that data for the GPU before the compute passes run.

The per-frame CPU upload is compact simulation state rather than a pre-rendered video frame. The integrated GPU then builds the image procedurally from that state.

CPU overhead: tick-based simulation

The simulation logic runs on the CPU at a base 20 ticks per second. Each tick spawns rain strings, advances their heads, and ages cells by decaying brightness until they fade out. The work is a compact deterministic state update over an array of cell descriptors.

Copy// ~20 times per second on CPU
spawnStrings()       // create new rain strings at random columns
advanceStrings()     // move each cursor downward, update head cell
ageCells()           // decay brightness, mark dead cells

The heavy lifting (compositing, bloom, color mapping, and glyph rendering) is GPU compute. The CPU advances the simulation state machine at a base 20 ticks per second. Exact utilization depends on the connected displays and current quality tier.

GPU work scales with display resolution

The main and final passes cover the full drawable, while bloom runs on smaller intermediate textures. More pixels and more connected displays therefore create more GPU work.

Most output pixels are computed independently; the blur passes sample neighboring pixels. Metal dispatches the work in threadgroups across the selected device.

Matrix Desktop does not publish a single utilization number because resolution, display count, preset, render mode, chip, and system conditions all change the result.

Apple Silicon models use the same Metal path

Mac Mini, Mac Studio, MacBook Air, MacBook Pro, iMac, and Mac Pro models with Apple Silicon all run the same Metal shader code. Available GPU capacity and thermal behavior still vary by chip and enclosure.

No discrete GPU is required. Matrix Desktop is built for the integrated GPU in Apple Silicon Macs.

Matrix Desktop also works on a headless Mac Mini when macOS has an active graphical session or virtual display. Its adaptive quality controls remain active during remote use.

Adaptive quality backs off under pressure

Matrix Desktop monitors system conditions and reduces rendering work on battery, in Low Power Mode, or under serious thermal pressure.

Copy// Monitor thermal state via ProcessInfo
let thermalState = ProcessInfo.processInfo.thermalState

// Monitor power source via IOKit
let isOnBattery = IOPSCopyPowerSourcesInfo()...

// Choose the worst tier required by any signal
var tier = QualityTier.full
if thermalState == .serious { tier = .medium }
if thermalState == .critical { tier = .low }
if isOnBattery || ProcessInfo.processInfo.isLowPowerModeEnabled {
    tier = max(tier, .medium)
}

targetFPS = tier.targetFPS       // 60, 30, or 15
bloomEnabled = !tier.skipBloom  // disabled at medium/low

The three quality tiers:

• Full (60 fps, bloom enabled): Used on AC power when thermal state is nominal or fair and Low Power Mode is off.
• Medium (30 fps, bloom skipped): Used on battery, in Low Power Mode, or at serious thermal state.
• Low (15 fps, bloom skipped): Used at critical thermal state.

This does not promise zero resource use, but it gives the wallpaper a defined way to back off when the Mac reports power or thermal pressure.

Triple buffering: safe resource reuse

The renderer maintains three sets of cell and uniform buffers that rotate behind a counting semaphore. The semaphore prevents the CPU from reusing a buffer until the GPU command that consumed it has completed.

Copy// Wait for a buffer to become available
frameSemaphore.wait()

let bufferIndex = currentBuffer % 3
updateSimulationState(into: uniformBuffers[bufferIndex])

commandBuffer.addCompletedHandler { [weak self] _ in
    self?.frameSemaphore.signal()
}

// Submit GPU work and advance
commandBuffer.commit()
currentBuffer += 1

Triple buffering reduces CPU/GPU contention and allows several frames to be in flight while still bounding resource reuse.

Per-screen Metal device selection

macOS exposes the Metal device associated with each display. Matrix Desktop asks for that device when it creates a renderer, with the system default Metal device as a fallback.

Copy// Get the Metal device for a specific display
if let displayID = screen.deviceDescription[
    NSDeviceDescriptionKey("NSScreenNumber")
] as? CGDirectDisplayID,
   let displayDevice = CGDirectDisplayCopyCurrentMetalDevice(displayID) {
    return displayDevice
}

return MTLCreateSystemDefaultDevice()

Matrix Desktop creates a separate renderer per connected screen. On Apple Silicon, the screens normally resolve to the same integrated Metal device, while each display still keeps independent windows, simulation state, and render resources. Display connections and removals are handled automatically.

Why this matters for vibe coders

If you run heavy compile, ML, or virtualized workloads, the useful behavior is predictable backoff: battery and thermal signals lower the target frame rate and disable bloom.

How the workloads relate:

• Xcode builds: Compilation is primarily CPU work, while the wallpaper's pixel work is Metal compute.
• ML and local inference: These workloads can also use the GPU; thermal and power backoff therefore matter.
• Docker / Linux VMs: Virtualized workloads still share CPU and memory with the app.
• Video calls: The wallpaper remains a separate desktop-level render surface and can be paused manually when desired.

Exact impact varies by Mac and display setup. The app provides automatic quality reduction plus a menu-bar Pause action when the user wants to stop rendering entirely.