Is WindowServer smoother (now on Metal)?

[FatalFallacy]

Dev beta 5 still having massive issues with hanging/crashing/restarting WindowServer for me (mostly while rendering complex websites within Chrome), caused by GPU-driver restarts or GPU unresponsiveness with the GT650m (original 2012 MBPr) connected to an external screen.

Stacks/spinlogs point to the Metal shader implementation itself, so I suspect a gfx driver software issue with these nVidia-cards, no improvements found so far since the first HS beta.

Especially as my main Sierra environment is behaving rock solid from this perspective and my logic board has been replaced shortly I'd rule out a GPU hardware issue/overheating problem.

 

[ryxn]

Dev beta 5 still having massive issues with hanging/crashing/restarting WindowServer for me (mostly while rendering complex websites within Chrome), caused by GPU-driver restarts or GPU unresponsiveness with the GT650m (original 2012 MBPr) connected to an external screen.

Stacks/spinlogs point to the Metal shader implementation itself, so I suspect a gfx driver software issue with these nVidia-cards, no improvements found so far since the first HS beta.

Especially as my main Sierra environment is behaving rock solid from this perspective and my logic board has been replaced shortly I'd rule out a GPU hardware issue/overheating problem.

That's interesting, does your main machine use Nvidia graphics or AMD? I'm on AMD for mine and have had no issues.

 

[294307]

That's interesting, does your main machine use Nvidia graphics or AMD? I'm on AMD for mine and have had no issues.

FatalFallacy mentioned the NVIDIA GT650M in the original post. I too haven't had any issues with the WindowServer crashing - but like you, I'm using an AMD GPU here.

 

[FatalFallacy]

FatalFallacy mentioned the NVIDIA GT650M in the original pos

If I use the internal screen only, windowserver seems to be quite stable for me as well (independently whether dedicated or internal gpu is used or enforced).

Once in clamshell mode with an external screen connected (running @1920x1080, MacOS automatically enforcing the GT650m) I am facing these random windowserver crashes or hanging, so could be related to the setup.

Anyway, bug report has been filed for some time now.
As WindowServer restarts take down all running applications with it when relaunching to the gui-login-screen, currently no chance for me considering the beta for daily usage (which is absolutely fine for a beta).

 

[floyd25]

I'm also having these issues with an Nvidia GT750m. I usually use the screen scaling feature to upscale the display a little bit but this is constantly crashing since beta 1 and even in beta 5. Using display scaling also results in very poor overal gfx performance.

Btw. using the native screen resolution without having MacOS scale the display content it's usually crashing less. Maybe that will help someone

 

[F1Mac]

Resizing mostly relies on application code (what's in the drawRect() methods), which usually does not involve the GPU. The Window server has very limited impact there. Or at least, windows compositing by the GPU is no the limited factor when resizing, so OpenGL is already fast enough.

I have the impression that in general, resizing was smoother in the Mavericks era, though it's hard to say whether it's due to changes in specific application code or in AppKit. I find borderline inacceptable that in 2017, apps like Mail and the Finder are still sluggish when it comes to resizing windows and columns.

I've always been under the impression that it was smoother in Mavericks because there was much less bells and whistles back then than the stuff introduced in Yosemite (transparency to name one). Resizing was indeed faster, and less taxing in 10.9. In sierra it's now about the same as in Mavericks, but the cpu has more to do. My mid-2012 Mac Pro doesn't really care, but it's much more noticeable on older hardware.
[doublepost=1502657515][/doublepost]

It feels smoother on OpenGL too.

That's good to know!

 

[voodoomaniac]

Hi. I am new at macOS and I'm dissapointed about lack of smoothness in both Sierra and High Sierra. I have recorded an example of poor performance on iTunes and iBooks window resize

Such behavior is observed for some other apps and I'm wondering does someone have the same problems?

 

[jeanlain]

iTunes is an abomination of an app that is written with old technologies, probably to facilitate the development of the Windows version. It it used core animation (which it most certainly doesn't), at least animations would be smooth.
iBook Store, I don't know. The UI code is probably poorly written. The App Store window doesn't resize very well either. I've always wondered why, since Safari is so smooth in comparison despite showing more complex content.

This doesn't have much to do with High Sierra in particular. This is application-specific.

 

[EugW]

iTunes is an abomination of an app that is written with old technologies, probably to facilitate the development of the Windows version. It it used core animation (which it most certainly doesn't), at least animations would be smooth.
iBook Store, I don't know. The UI code is probably poorly written. The App Store window doesn't resize very well either. I've always wondered why, since Safari is so smooth in comparison despite showing more complex content.

This doesn't have much to do with High Sierra in particular. This is application-specific.

iTunes was originally written only for the Mac, but that was eons ago. Windows support only came later. But still, its legacy roots on both sides probably is significant here for smoothness.

 

[voodoomaniac]

iTunes is an abomination of an app that is written with old technologies, probably to facilitate the development of the Windows version. It it used core animation (which it most certainly doesn't), at least animations would be smooth.
iBook Store, I don't know. The UI code is probably poorly written. The App Store window doesn't resize very well either. I've always wondered why, since Safari is so smooth in comparison despite showing more complex content.

This doesn't have much to do with High Sierra in particular. This is application-specific.

Most of 3rd party apps act the same on my iMac 5k screen. I thought that bringing Metal 2 to High Sierra will resolve this problem but looks like I was wrong.

 

[jeanlain]

Resizing is generally smooth on my 5K iMac (2017).
Resizing performance is largely independent of Metal since it doesn't affect other windows (Window server) and is generally not managed by core animation. It mostly depends on how developers code their UI, in particular the drawRect() method to display the content of a view. You can do it lazily and just redraw everything regardless of the change, or try to optimise and determine what really needs to be redrawn. The later takes more work.
For instance, the Finder used to be slow to resize a window in column view if folders had a lot of files, even if only a few files were visible. All the icons were likely being redrawn, even those that were not visible. The Finder in high Sierra fixes that.
The Messages window can be very slow to resize when you scroll far up a long conversation, even though the window doesn't show more than what it shows at the bottom of the conversation. I suspect all bubbles from the current point down to the bottom are redrawn, even if most are not visible. Another possibility is that they simply need to compute the height of the discussion inside the scroll view (just to correctly position the scroll bar), and that alone may take time if there are many bubbles, because the size of a each character string must be estimated, which depends on font, etc.
Anyway, nothing can fix that expect rewriting the app to make it do less useless things.

 

[Cougarcat]

I've always been under the impression that it was smoother in Mavericks because there was much less bells and whistles back then than the stuff introduced in Yosemite (transparency to name one). Resizing was indeed faster, and less taxing in 10.9. In sierra it's now about the same as in Mavericks, but the cpu has more to do. My mid-2012 Mac Pro doesn't really care, but it's much more noticeable on older hardware.

I don't think so. I keep translucency off for aesthetic reasons, and I don't notice a difference between the settings. (But yes, maybe it is more noticeable on older hardware.)

 

[jeanlain]

iTunes was originally written only for the Mac, but that was eons ago. Windows support only came later. But still, its legacy roots on both sides probably is significant here for smoothness.

Apple have now rewritten all their ancient carbon apps. From the Finder, to iMovie, to FCP. Only the old DVD player wasn't rewritten (it's still carbon and 32-bits), but that's understandable.
Even though iTunes is no longer carbon and is 64 bit, it's very far from being a modern app. Apple just keeps adding lipstick on this pig, trying to mimic the behaviour of AppKit classes (like NSScrollView) but utterly failing at it. I strongly suspect that they use some Frankenstein code base that they maintain only because it is shared with the the Windows version. It's a bit like the Steam app actually. A cocoa UI would be harder to port to Windows.

 

[EugW]

Apple have now rewritten all their ancient carbon apps. From the Finder, to iMovie, to FCP. Only the old DVD player wasn't rewritten (it's still carbon and 32-bits), but that's understandable.

Hmmm... So I guess we lose DVD player next year.

 

[KoolAid-Drink]

Hmmm... So I guess we lose DVD player next year.

Hopefully not. I’m sure Apple will convert it to 64-bit. Even though none of Apple’s devices come with optical drives these days, they still sell their optical drives in the store.

 

[Cougarcat]

Hopefully not. I’m sure Apple will convert it to 64-bit. Even though none of Apple’s devices come with optical drives these days, they still sell their optical drives in the store.

Wouldn't be surprised if Apple just stops selling it.

 

[KoolAid-Drink]

Wouldn't be surprised if Apple just stops selling it.

Yeah but what would happen to those customers who had bought the optical drives- they’d have less than a year to use it. Besides, many people still own DVDs.

 

[Cougarcat]

Yeah but what would happen to those customers who had bought the optical drives- they’d have less than a year to use it. Besides, many people still own DVDs.

They could still use them, they'd just have to find an alternative to DVD Player if Apple doesn't update it.

Anyway, I don't expect the 32-bit apocalypse til the end of 2019. Next year we'll have a warning dialog with 12.14, just like with iOS.

 

[KoolAid-Drink]

They could still use them, they'd just have to find an alternative to DVD Player if Apple doesn't update it.

Anyway, I don't expect the 32-bit apocalypse til the end of 2019. Next year we'll have a warning dialog with 12.14, just like with iOS.

Can you really imagine Apple would allow DVD Player to present a warning dialog every time? That’d be unprofessional, especially for their very own in-house application.

 

[Cougarcat]

Can you really imagine Apple would allow DVD Player to present a warning dialog every time? That’d be unprofessional, especially for their very own in-house application.

Sadly, yes. Though you have a point––if they don't plan on updating it then they'll just get rid of it next year.

 

[voodoomaniac]

Resizing is generally smooth on my 5K iMac (2017).

Do you have the same UI performance issues like I showed on the video?

Resizing performance is largely independent of Metal since it doesn't affect other windows (Window server) and is generally not managed by core animation. It mostly depends on how developers code their UI, in particular the drawRect() method to display the content of a view. You can do it lazily and just redraw everything regardless of the change, or try to optimise and determine what really needs to be redrawn. The later takes more work.
For instance, the Finder used to be slow to resize a window in column view if folders had a lot of files, even if only a few files were visible. All the icons were likely being redrawn, even those that were not visible. The Finder in high Sierra fixes that.
The Messages window can be very slow to resize when you scroll far up a long conversation, even though the window doesn't show more than what it shows at the bottom of the conversation. I suspect all bubbles from the current point down to the bottom are redrawn, even if most are not visible. Another possibility is that they simply need to compute the height of the discussion inside the scroll view (just to correctly position the scroll bar), and that alone may take time if there are many bubbles, because the size of a each character string must be estimated, which depends on font, etc.
Anyway, nothing can fix that expect rewriting the app to make it do less useless things.

During resize of some windows CPU is loaded up to 60% and even despite of this the FPS count is not more then 10. My assumption is that this could be claimed as defect which is have to be fixed. What do you think?

P.S. Now its interesting for me to install Windows 10 on my Mac and to test iTunes there. This will be very funny if fps will be ok there.

 

[jeanlain]

During resize of some windows CPU is loaded up to 60% and even despite of this the FPS count is not more then 10. My assumption is that this could be claimed as defect which is have to be fixed. What do you think?

I depends on expectations. Some may say that 0.1s to resize is acceptable. But it could certainly be improved.