# Fix WindowServer High CPU on Mac > Isolate redraws, capture tools, displays, scaling, and refresh rate while comparing a stable WindowServer baseline. Published: 2026-06-21 | Updated: 2026-07-25 WindowServer is the macOS display compositor. Its CPU use reflects the work required to combine app surfaces across displays, but the process name does not reveal which app is causing repeated redraws. A high number during animation, screen sharing, or a display change can be normal. The useful signal is sustained load at idle plus a measurable effect on responsiveness, heat, or battery life. ## What WindowServer actually is WindowServer is the macOS compositor. Every window, menu, animation, and pixel you see is drawn and combined by it, across every display. Because it touches everything on screen, a heavy graphical workload shows up as WindowServer CPU rather than under the app causing it. That makes it look like the culprit when it is really the messenger. ## What drives it up A handful of things make WindowServer work harder: - **Many windows and Spaces.** Dozens of open windows and a pile of virtual desktops all have to be tracked and composited. - **External and high-resolution displays.** More pixels to push, especially a 4K or 5K screen, or several monitors at once, raises the baseline steadily. - **Scaled resolution.** Running a display at a non-native "looks like" resolution can require a larger render surface and downsampling. The cost depends on the Mac, display, scaling mode, and workload; Retina scaling itself is normal. - **Transparency and motion.** The blur and translucency in menus, the Dock, and Control Center are all live effects WindowServer computes continuously. - **A window-heavy app redrawing constantly**, such as a terminal printing fast or a page animating in the background. - **Capture and remote-display software.** Screen recording, video calls, AirPlay, remote desktop, and virtual-display tools add capture or composition work. - **High refresh rates and animated desktops.** More frames or continuously changing pixels increase the amount of work even when you are not touching a window. ## How to calm it Work through the cheap wins first: - **Reduce transparency:** open **System Settings > Accessibility > Display**, then enable **Reduce transparency**. Apple's [Display settings guide](https://support.apple.com/guide/mac-help/unac089/mac) describes the visual change. It may reduce live effect work, but compare the same scene before keeping it as a performance fix. - **Reduce motion:** this now has its own **Accessibility > Motion** panel. Apple's [Motion guide](https://support.apple.com/guide/mac-help/mchlc03f57a1/mac) says it changes animations for actions such as opening apps and switching desktops. - **Test the default display scale** or a lower refresh rate, then compare the same workload. Do not sacrifice readable text based on the assumption that all scaling is bad. - **Close windows and collapse Spaces** you are not using, and quit apps that redraw heavily in the background. - **Pause screen recording, remote desktop, animated wallpaper, or virtual displays** one at a time to identify the owner. - **Disconnect one display** as a diagnostic. If that changes the baseline, test its scale, refresh rate, cable, and adapter separately. Log out and back in only after collecting evidence; this restarts the user display session. A reboot can hide a redraw bug without identifying the app that will trigger it again. Do not evaluate only the instantaneous percentage. In Activity Monitor, watch the same idle scene for a few minutes, reproduce one animation or capture workload, then remove one suspected source. WindowServer should be judged with the symptom: smoother input, lower heat, or better battery behavior. A lower number with no visible or thermal improvement is not a useful fix. ## Under the hood: the compositor, and why scaling costs WindowServer is a compositor. Every app draws into its own offscreen buffer, a backing store, and WindowServer combines those buffers into the final image for each display, applying transforms and effects as it goes. Compositing runs whenever the scene changes, so constant redraws and capture can cost CPU or GPU continuously. Some scaled modes use a larger intermediate surface and downsample it, but that is only one possible contributor. Pixel count, refresh rate, display count, and redraw frequency must be tested independently.
Several app backing stores feed a compositor that outputs one display image, with scaled resolution shown rendering larger then downsampling to the panel's native pixels.
WindowServer combines app surfaces for each display. Scaling, refresh rate, capture, and repeated redraws can each add work to that composition pipeline.
## Where a monitor helps Activity Monitor or [Mole](https://mole.fit/)'s Status view can show WindowServer, CPU, and GPU trends, but neither can automatically assign compositor cost to one app. The reliable method is controlled isolation: stop one redraw source or change one display variable, then compare the idle and workload baselines. ## A repeatable diagnosis Measure WindowServer at idle and during the problem, then isolate animated content, capture tools, displays, scale, and refresh rate one at a time. Keep the change only when both the metric and the user-visible symptom improve. Do not force-quit WindowServer or treat an ordinary Retina scale as a fault. --- Canonical HTML page: https://mole.fit/blog/windowserver-high-cpu-mac Blog index for agents: https://mole.fit/blog/llms.txt Site index for agents: https://mole.fit/llms.txt