Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
So then should we expect any differences with regards to screen resolution, amount of video RAM, and speed of GPU? What about CPU speed?

I'll have to try this on my iMac 2017 5K with i5-7600 and 575, once I get the proper adapters to use my 2010 iMac as an external monitor. My friend with a late 2014 i5-4690 iMac complains about Mission Control stuttering in Sierra. I believe he would have the Radeon R9 M290X.
 
On the one hand, Windowserver is noticeably smoother on my 2013 retina MacBook Pro. On the other hand, sometimes it just blows up and the screen goes nuts, and sometimes it just crashes (which essentially does an immediate emergency logout without giving any warning to the system, so hey there data loss). Duet display definitely causes Windowserver to crash. And by “sometimes” I mean “one to three times per day.”

Hopefully the next beta will have significant improvements to stability, with any luck!
 
On the one hand, Windowserver is noticeably smoother on my 2013 retina MacBook Pro. On the other hand, sometimes it just blows up and the screen goes nuts, and sometimes it just crashes (which essentially does an immediate emergency logout without giving any warning to the system, so hey there data loss). Duet display definitely causes Windowserver to crash. And by “sometimes” I mean “one to three times per day.”

Hopefully the next beta will have significant improvements to stability, with any luck!

Really good news. I'm on a 2015 MBPR and every since I got my MBPR, mission control has been a nightmare to the point where I barely even ever use it. I used to use it all the time on MBP NON-RETINA If it's smooth again then 50% of the OSX functionality is back!
 
I suppose that when you drag a window, it still slightly lags behind the pointer?

Yes. It still happens and it is still highly frustrating.

While poking and prodding the system in an attempt to narrow down the cause, I inadvertently stumbled upon a solution. If you have a classic Mac Pro, you can attach a secondary GPU to the system and disable its driver. This will force said GPU to run in framebuffer fallback mode, eliminating the window drag delay for the primary GPU. It also produces the secondary effect of increased mouse input latency, which got me thinking.

I believe this is a vsync issue, as the delay between the movement of the cursor and window always appears to be approximately 32ms. This would be consistent with the fact that OS X's compositor employs double buffering.

This is purely speculation but I would guess that Apple chose to draw the cursor independently of WindowServer in order to address the issue of mouse input latency, which was once a well known problem under OS X. In doing so, they introduced this new issue, which would explain the 32ms delay.

In fact, the same behavior can quite easily be observed under Windows, where the cursor is drawn separately from the Aero compositor. Simply grab a desktop icon and drag it around. You will notice exactly the same (albeit 16ms due to the absence of double buffering) delay that is found under OS X.

Which leads me to a more feasible solution. Windows must be eliminating the window drag delay with a little bit of (almost) seamless trickery. You may notice that upon clicking a titlebar under Windows, the mouse always flickers once. I believe this flicker signifies a transition from the cursor being drawn independently to becoming part of the compositor for the duration of the window drag.

This conclusion is borne out by the increased mouse latency felt while dragging windows under Windows, which means that Apple could quite easily implement a similar solution.

EDIT: In fact, I believe that it should be possible to fix this issue with a third party application. Hide the cursor when a window titlebar has been clicked, draw a new cursor onto the titlebar and reverse when the mouse is released.
 
Last edited:
Hmmm... I loaded a bunch of Safari windows as well as a whole bunch of other apps on a couple of desktops on my 2017 i5-7600/575 4 GB video RAM and 24 GB system RAM. macOS 12.10.5 (16F2073). I didn't notice any choppiness in Mission Control unless an application was still loading.

Thinking it may just be the new much faster machine (CPU and esp. GPU), I tried the same thing on my 2010 iMac i7-870 / 5750 with 1 GB video ram and 12 GB system RAM. macOS 12.10.5 (16F73). That seemed fine too.

Where is the choppiness I should be looking for? I did notice it on my old 2009 MacBook Pro in older OS X versions, but it doesn't run High Sierra (without a hack) so I can't compare it.
 
@Troy2000 You'll probably enjoy these blog posts (see links in the article):

http://iaintnoextra.tumblr.com/post/31374405045/john-carmack-and-osx-mouse-lag
Resultant software that "fixed" this, but got deprecated by Sierra: http://smoothmouse.com

This has never really bothered me, I ran Smoothmouse and some of the other options (Exactmouse etc.) out of curiosity but the improvement was not really significant enough to bother with; but other users find macOS mouse lag super annoying. The smoothmouse developer claims the major 16ms lag was actually fixed in El Capitan:

http://dae.me/blog/2144/on-macos-sierra-support-and-the-future-of-smoothmouse/
 
@Troy2000 You'll probably enjoy these blog posts (see links in the article):

http://iaintnoextra.tumblr.com/post/31374405045/john-carmack-and-osx-mouse-lag
Resultant software that "fixed" this, but got deprecated by Sierra: http://smoothmouse.com

This has never really bothered me, I ran Smoothmouse and some of the other options (Exactmouse etc.) out of curiosity but the improvement was not really significant enough to bother with; but other users find macOS mouse lag super annoying. The smoothmouse developer claims the major 16ms lag was actually fixed in El Capitan:

http://dae.me/blog/2144/on-macos-sierra-support-and-the-future-of-smoothmouse/
Yes, they are correct. El Capitan did resolve the mouse input latency problem, as mentioned in my post above. In doing so, they introduced a new issue wherein windows trail the cursor by 32ms when dragged.
 
The delay between mouse movement and window movement existed before El Capitan. Some say it appeared in Lion. I know it has been there since at least since Mavericks.
 
The delay between mouse movement and window movement existed before El Capitan. Some say it appeared in Lion. I know it has been there since at least since Mavericks.
Technically speaking, it has been present since Yosemite. Under Mavericks and prior releases, Apple appears to have implemented measures to hide the independently-drawn cursor but only for specific GPUs.

I recall experimenting with the issue under Mavericks several years ago and finding that when an unofficially supported GPU was attached, two cursors were visible when dragging windows. The gap between them was approximately 32ms.

I don't quite understand how they dealt with this under Lion and Mountain Lion. Under normal circumstances there is no delay at all but if the system is under sufficient stress, it will begin to occur intermittently. I can only speculate that it has to do with the GPU being too busy to accurately draw the "static" cursor within WindowServer.
 
The performance is definitely better with High Sierra. But since I'm having an Mac Mini 2012 (Intel HD 4000) with two 2k Displays there's still some room for improvement when having a lot of windows in Mission Control. I also had the feeling that the animations were a little bit faster. But maybe that's just caused by the better frame rate on High Sierra.
 
Anyone with a 13" MBP/TB outputting to 5k monitor find a performance improvement? Its one area where its often quite laggy.
 
In fact, the same behavior can quite easily be observed under Windows, where the cursor is drawn separately from the Aero compositor. Simply grab a desktop icon and drag it around. You will notice exactly the same (albeit 16ms due to the absence of double buffering) delay that is found under OS X.
Indeed I see the mouse flicker you're talking about on Windows 10 and it looks like it introduces a delay between mouse movement and pointer movement.
Interestingly, when clicking and dragging on the empty desktop, the selection rectangle clearly lags behind the pointer in windows 10, while there is lo lag whatsoever on macOS. I believe this operation doesn't involve window compositing/quartz extreme/openGL stuff, as opposed to dragging a window.
 
The cursor flicker is present on all Windows installations. It is simply a product of switching between compositor drawn and independently drawn cursors.

It's never been seen on my installs, unless you're seeing something that most of us wouldn't be bothered about or notice.
 
The question is not whether the flicker is bothering, it's an indication that Windows does something special to eliminate the delay between mouse movement and windows movement when you drag a window.
 
  • Like
Reactions: Troy2000
The question is not whether the flicker is bothering, it's an indication that Windows does something special to eliminate the delay between mouse movement and windows movement when you drag a window.
Precisely.

This is a short slow motion clip demonstrating the effect. At 60Hz, it occurs for only 1/60th of a second and is not something that you are likely to notice, unless you are specifically looking for it.

 
WindowServer's upgraded to Metal is perhaps the thing I am l looking forward the most.

On my 2016 MacBook, WindowServer is always choppy when starting mission control. Has anyone noticed a change in this on High Sierra?

The WindowServer/metal improvements with mission control have tempted me to move my main work machine (a 5k iMac) to High Sierra. My 2016 MBP (with Touch Bar, etc) loves the new WindowServer ... mission control is so smooth it's a joy to slowly slide three fingers up and down the track pad to watch the windows seamlessly expand and contract into place. My one hesitation is that, at least on my MBP, Mail.app is constantly burning the CPU and generating nasty latency across the entire OS ... and I depend on Mail too much to not be able to run it on my iMac. If the next patch (next week hopefully?) cures my MBP of the CPU-assaulting Mail.app, I'll move my iMac to High Sierra.
 
Might have been mentioned, but is the switch desktop movement smoother now as well? That can be really slow here.
 
Might have been mentioned, but is the switch desktop movement smoother now as well? That can be really slow here.

I generally don't have any issues with desktop switching, but that's equally as smooth, yes.
 
  • Like
Reactions: T-Bob
Anyone with a 13" MBP/TB outputting to 5k monitor find a performance improvement? Its one area where its often quite laggy.

Yep it's better. Still not enough of a boost to use higher scaling though (for now).
 
Yes. It still happens and it is still highly frustrating.

While poking and prodding the system in an attempt to narrow down the cause, I inadvertently stumbled upon a solution. If you have a classic Mac Pro, you can attach a secondary GPU to the system and disable its driver. This will force said GPU to run in framebuffer fallback mode, eliminating the window drag delay for the primary GPU. It also produces the secondary effect of increased mouse input latency, which got me thinking.

I believe this is a vsync issue, as the delay between the movement of the cursor and window always appears to be approximately 32ms. This would be consistent with the fact that OS X's compositor employs double buffering.

This is purely speculation but I would guess that Apple chose to draw the cursor independently of WindowServer in order to address the issue of mouse input latency, which was once a well known problem under OS X. In doing so, they introduced this new issue, which would explain the 32ms delay.

In fact, the same behavior can quite easily be observed under Windows, where the cursor is drawn separately from the Aero compositor. Simply grab a desktop icon and drag it around. You will notice exactly the same (albeit 16ms due to the absence of double buffering) delay that is found under OS X.

Which leads me to a more feasible solution. Windows must be eliminating the window drag delay with a little bit of (almost) seamless trickery. You may notice that upon clicking a titlebar under Windows, the mouse always flickers once. I believe this flicker signifies a transition from the cursor being drawn independently to becoming part of the compositor for the duration of the window drag.

This conclusion is borne out by the increased mouse latency felt while dragging windows under Windows, which means that Apple could quite easily implement a similar solution.

EDIT: In fact, I believe that it should be possible to fix this issue with a third party application. Hide the cursor when a window titlebar has been clicked, draw a new cursor onto the titlebar and reverse when the mouse is released.



Great post!

I'd really rather lose double buffering and get down to 16ms window drags like Windows, rather than have a perfectly untorn, visibly lagging window resize like macOS.

I expect at this point, Apple won't fix it. The reason I wager is that ProMotion will be making it to Macs, and with a freely adapting monitor refresh rate and 120Hz, we'll get down to 8ms minimum and also smoother for missed frames, since the monitor can just update when the GPU is ready rather than waiting another 16ms (32 for double buffering).


That will, alas, still leave everyone with 60hz macs including all 2017 models, with the laggy resize if it's never changed in software, which is crazy that we still have that much lag this year.
 
The WindowServer/metal improvements with mission control have tempted me to move my main work machine (a 5k iMac) to High Sierra. My 2016 MBP (with Touch Bar, etc) loves the new WindowServer ... mission control is so smooth it's a joy to slowly slide three fingers up and down the track pad to watch the windows seamlessly expand and contract into place. My one hesitation is that, at least on my MBP, Mail.app is constantly burning the CPU and generating nasty latency across the entire OS ... and I depend on Mail too much to not be able to run it on my iMac. If the next patch (next week hopefully?) cures my MBP of the CPU-assaulting Mail.app, I'll move my iMac to High Sierra.

I've definitely noticed a massive improvement in Mission Control performance in 10.13 High Sierra on my iMac with the Radeon Pro 570 GPU when I tested it on a separate partition (compared to 10.12 Sierra - Mission Control often can't handle more than a dozen windows before animations stall). I'll be interested to hear how the latest beta performs on your iMac - I did notice some improvements between the first and third beta I had tried.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.