Switching Spaces is significantly slower when Sketchybar is running

[AlecSchneider]

Heya,

happening on both my Mac Laptops. M1 Pro / M2. Whenever I have sketchybar running switching between spaces is significantly slower (like up to 2-3s delay with the default config in the repo).

If I remove spaces / calendar... all the default widgets - it does speed up but still slower than without running sketchybar :/

any ideas?

OS: macOS 12.5 21G72 arm64
Host: Mac14,2
Kernel: 21.6.0
Uptime: 1 day, 1 hour, 16 mins
Packages: 171 (brew)
Shell: zsh 5.8.1
Resolution: 2048x1332@2x
DE: Aqua
WM: yabai
Terminal: tmux
CPU: Apple M2
GPU: Apple M2
Memory: 2974MiB / 16384MiB

[FelixKratz]

I did some quick testing and I know why this is happening. I will need to take some time to work on this and create a fix for it. It is not a problem with sketchybar a priori, but with how the WindowServer handles SketchyBar in animations. The fix will unfortunately include making sketchybar not "sticky" anymore, meaning that SketchyBar will only be drawn on the active space and as soon as the space change animation finishes sketchybar will reappear on the newly active space.

I have disabled those animations, which is why I did not notice this before, so thanks for the report.

[AlecSchneider]

How where you able to disable those animations? Best I've been able to do is "Reduce Motion" config change in sys pref

[FelixKratz]

You can completely disable space change animations via the scripting addition of yabai, its much snappier this way.

[es183923]

Perhaps you could detect if the yabai scripting addition is installed, and use the "sticky" method if it is, or the other method if it isn't.

[FelixKratz]

Perhaps you could detect if the yabai scripting addition is installed, and use the "sticky" method if it is, or the other method if it isn't.

Even if it is installed, it may not be loaded. So I would need to detect if yabai has actually loaded the addition, but I think this gets a bit too sketchy.

I am in every case keeping the "sticky" implementation around, because I think it is the canonical implementation. Probably I will introduce a new property:

sketchybar --bar sticky=<boolean>

which is off by default, such that people with disabled animations can turn it on and are not disturbed with a visual flicker on space change.

[AlecSchneider]

Even with yabai. If you use gestures / CTRL+ arrow keys it's still using the old animations right?

[FelixKratz]

Can you test this commit: 743c9c8
It contains the previously mentioned fix and the new sticky bar property. Please report if the issue is fixed by this. I have not tested this implementation with a secondary monitor, but I think I have thought about that...

[AlecSchneider]

looks like that works!

Also only tested on 1 (laptop) screen

[FelixKratz]

The fixes discussed here are contained in the most recent release.

[FelixKratz]

It seems this problem no longer exists on macOS Sonoma. Can anyone confirm that even when having sketchybar --bar sticky=on the desktop switching is not laggy on Sonoma?

[ralphptorres]

Can confirm, though I don't have yabai's scripting addition and I can't compare it with pre-Sonoma behavior (didn't use sketchybar prior to Sonoma). But I can say desktop switching with sticky=on is as snappy as with sticky=off.

[FelixKratz]

Thanks for confirming. Prior to Sonoma it was a real problem, it was significantly slower, like 4x slower at times. It seems apple has fixed the bug in WindowServer responsible for this.

I can not remove the sticky property because this is still a problem on older macOS versions but I could change the default value of the sticky property specifically for Sonoma to be on by default.

[ralphptorres]

I see. Thankfully it's fixed now.

An aside: perhaps one more reason not to remove sticky is it producing the more desirable behavior when switching desktops for users who don't have the switching animation disabled:

sticky-on.mov

When sticky is off, the bar items flicker as in

sticky-off.mov