To sum up:
- The problem has been confirmed by an Apple engineer (thanks to him for that) in an email correspondence with me. He has also mentioned that they were working on a solution.
- The problem has existed at least since OS X 10.4 "Tiger". The current version of OS X (10.8 "Mountain Lion") still exhibits the problem.
- Many people confuse lag with acceleration, this is what my blog post was about.
- Running Mac as a Synergy client with a mouse connected to another computer running Synergy server.
- Using Wacom tablet instead of a mouse.
Some technical insight provided by John Carmack:
You can measure all this objectively. I took a few minutes, pulled out my handy high speed camera, and shot some quick video dragging a window around on my windows desktop and my old macbook. I used the same mouse, a Razer DeathAdder, on both systems.
Someone with more time should do a more exhaustive set of tests with a tripod and a trivial app instead of window dragging to make the data cleaner, but the results are so dramatically different that it isn’t a matter of splitting hairs.
Even being generous with exactly which frame the mouse started moving on, I never counted less than 10 frames (at 240 hz = 42 milliseconds) and sometimes as many as 17 from the time the mouse moved to the time the pixels on the screen started to change. I’m sure this is better on a more modern system.
The PC result was surprising. I was running on a 120hz monitor, and I couldn’t positively identify any frames of latency between the mouse starting to move and pixels on the screen changing.
The mac does tear-free, retrace-synced desktop compositing, which means that a window at the bottom of the screen will always update 14 milliseconds later than one at the top of the screen due to a 60hs scanout. I don’t know the internal details, but it is possible that there may be a full frame of latency involved in latching the stable output of each window in preparation for the compositor, which would roughly line up with the observed data.
The windows system (not running with Aero, which is probably significant here!) apparently gets a new mouse update ever 2 milliseconds and moves the window immediately. This is why you get tear lines while dragging windows, and there were other temporal repainting artifacts visible in the high speed video.
Apple made a (presumably) conscious decision to sacrifice responsiveness for perfect pixels.
Again, someone could make a more direct comparison of similarly configured systems and write a real article about the results. It is also possible (likely?) that full screen 3D apps may bypass the desktop compositing and not suffer from any of this.
Another useful comment by Matthijs:
32ms… that sounds like the time taken to display two screen frames at 60 Hz.
Observation: when I quickly select text using the mouse, there is no lag between the mouse cursor and the selection of text.
I’m assuming Mac OS X uses double buffering for graphics. Here’s what I think is happening in the worst case:
If the assumption is correct, this leads to the following conclusions:
- A frame is drawn onto the back buffer. (current time: 0ms)
- You move the mouse just after this is done. (current time: 0ms)
- After the next vsync, the back buffer is drawn. (current time: 16ms)
- A new frame is drawn onto the back buffer, with the new mouse position. (current time: 16ms)
- After the next vsync, the back buffer is drawn. (current time: 32ms)
Regarding Windows: I suspect Windows uses a different, ancient technique to draw the mouse cursor: sprites. With active sprites, the GPU draws them on top of the displayed frame without having to manually draw them into the back buffer. If this is true, selecting text (like the observation above) will result in the selection lagging after the mouse cursor.
- The mouse itself does not lag, but merely the graphical representation of it.
- Your statement “Yes, Mac OS X is less suited for gaming and design.” is false. All games and design apps use double buffering (or in some cases, triple buffering), otherwise incomplete frames would be shown.
Note: if you have access to a display with a faster refresh rate than 60Hz, you will notice less mouse lag if you use that display. If my assumption is correct, of course.
(I disagree with conclusion #2. You can turn off double-buffering in most games. Design requires a lot of precise mouse work and lag does not help that).