M5 Pro external 5K 165Hz display: Window animations and scrolling UI appear to render at ~60Hz/jitter while cursor remains perfectly smooth

Question

KevinKung OP

Created 1d

Replies 3

Boosts 1

Participants 1

Hello Apple engineers,

I’m trying to determine whether what I’m seeing is expected behavior or a software issue with the new M5 Pro platform.

System

MacBook Pro (M5 Pro)
Latest macOS Beta
External 5K 165Hz monitor connected via DisplayPort
Refresh rate correctly detected as 165Hz

What I observe

The display itself is clearly running at 165Hz.

For example:

Mouse cursor movement is extremely smooth.
Dragging the desktop by holding an empty area is also perfectly smooth.

However:

Moving application windows feels much closer to 60Hz.
Scrolling in Safari, Chrome and other applications also appears to run at a much lower frame rate than the display refresh rate.
Mission Control animations sometimes show similar micro-stutters.

This makes the cursor and desktop movement noticeably smoother than normal window animations.

⸻

Troubleshooting already performed

Different DisplayPort cables
Different timing configurations
Different resolutions / HiDPI modes
DSC enabled and disabled
Refresh rate confirmed at 165Hz
Same behavior across multiple applications

The issue appears unrelated to the monitor itself because the cursor is clearly rendered at the full refresh rate.

⸻

Additional observation

Interestingly, I previously used another external 4K 144Hz HDR monitor and did not notice this behavior.

I also found another M5 Pro user reporting nearly the same issue:

external 165Hz display
smooth cursor
window dragging jitter / micro-stuttering

At the same time, I haven’t found similar reports from M4 Pro or the base M5 running the same monitor.

⸻

My question

Could this be related to the new M5 Pro display pipeline (WindowServer, Display Engine, or DCP)?

Is there any known issue regarding high-refresh-rate external displays on the M5 Pro platform?

Or is there additional diagnostic logging (WindowServer, DCP, Metal, etc.) that would help identify whether frames are actually being presented at the display refresh rate?

I’d be happy to provide:

sysdiagnose
WindowServer logs
Screen recordings
Display timing information
IORegistry dumps

if they would be helpful.

Thank you!

Answer 1

KevinKung OP

1d

system version is 27.0 Beta (26A5378j)

Answer 2

KevinKung OP

1d

Case / Feedback Reference Feedback ID: FB23616959 (Captured after the system format)

Answer 3

KevinKung OP

17h

Additional Findings from Crash Analysis

After analyzing multiple WindowServer crash reports, I noticed that the crashes are highly consistent.

Both crash logs terminate with an internal assertion (__assert_rtn) inside the same Apple display pipeline function:

CA::WindowServer::AppleDisplay::max_src_rect_width_by_pipes()

The call stack is consistently:

__assert_rtn CA::WindowServer::AppleDisplay::max_src_rect_width_by_pipes() CA::WindowServer::Server::get_display_info() _XGetDisplayInfo

This suggests that WindowServer is failing while calculating display pipeline parameters during display information processing, rather than due to a GPU hang, Metal failure, or a third-party application.

I also reviewed the CPU Resource Diagnostic generated for WindowServer. During periods of high CPU usage, most of the activity is concentrated in WindowServer’s display update and Core Animation pipeline (display updates and rendering preparation), rather than GPU recovery or driver timeout paths.

In addition, I did not find evidence of AGX GPU panics, IOAccelerator timeouts, Metal command buffer failures, or DisplayLink-related components in the collected logs.

These observations suggest that the issue may be located within WindowServer’s AppleDisplay/display pipeline implementation when driving this external high-resolution, high-refresh-rate display configuration.