Lag exiting the grid


I have this problem when using the grid to switch desktops on a MacBookPro8,2 running Mavericks:

Entering the grid is as fast as it was in Mountain Lion, but exiting it (when I click on a desktop) may take up to two or three seconds, during which the previews of many windows (most often Safari’s and Mail’s) get garbled.

It doesn’t happen if I don’t switch desktops (that is if I click on the desktop I was in when I invoked the grid) and sometimes it doesn’t happen when I switch to a desktop I was on very recently (but not always). In fact, it’s hard to find a pattern.

I’ve tried setting the “Zoom to overview grid animation” option to None and the “Backgrounds in the overview grid” option to Lo res or None, but that didn’t help. My grid is 4 x 4 and Dashboard is not in it, BTW. I have Circulation off, and transitions work perfectly and without any delay. I also have no delay at all if I invoke Mission Control and switch desktops from there. I also tried forcing the GPU to Integrated or Discrete but that didn’t change a thing either.

Admittedly I have a bunch of windows open (I often have several windows in each of my 16 spaces) but this was already the case with TotalSpaces 1 in Mountain Lion and I didn’t have this problem, then.

This is with TotalSpace2 2.0.5.



same issue here - when i click a new space there is lag going to a space with windows in it however an empty space goes instantly.


Hmm, I wonder what’s going on to make it so slow.

16 spaces with a few windows on each should be ok, particularly for a 2011 machine.

What happens when you click on another space in the overview grid is that we ask the system to change to that space, whilst keeping the overview grid showing.

When the system has finished its work changing space, we unshow the grid using the animation it you have it turned on.

If you set the overview grid animation to None, then the only thing taking the time ought to be the system space change.

That shouldn’t be slow though (we disable all system animations when doing that so it goes as fast as possible).

One thing to try - if you turn space transitions off (untick Use transitions in the transitions prefs) do the spaces change quickly?

Second thing to try - in this version of the code there are some changes to do with the overview grid that may help.

Particularly if you try this version with grid transitions set to None, I would be interested to know if there is any change.
(Also any other effects, such as slower to enter the overview grid).

i think that helped - i have all transitions and effects off to begin with. one thing i noticed is when i click a space a white border appears around the space and afterwards it switches to the space which causes a slight lag. i’m pretty sure this behavior did not exist in v1.x.

Hi Stephen,

I’ll need some time to confirm it with my weekday workload, but so far it seems that turning space transitions off does help a bit. I’m also running the 2.0.7, now.

Do you redraw or update the contents of the grid at some point in this process? Because this is when I see corrupted graphics in Safari and Mail windows. And those graphics problems correspond to the lag.



We don’t explicitly redraw the grid, but the windows you see in the overview grid do mirror the contents of the real windows.

I have an idea of another thing to try, but it’s going to take me a couple of days to implement and test it.

In the mean time do let me know if you get any more clue as to exactly what causes the issue.

I don’t have many new clues on what causes the problem, but I can confirm that it’s still here in the 2.0.7 you posted.

It definitely seems to be related with Apple’s Webkit, though. Because the graphical problem doesn’t affect Firefox (nor, surprisingly, Google Chrome) but only Safari and Mail.

Hi Stephen,

I still have this problem with the 2.0.9. Is there anything I could do to help you figure it out?



Hi Philippe

As you are running 2.0.9, does adding this command line setting help?

defaults write com.binaryage.TotalSpaces2 lowerMemoryUsage YES

Sorry for the delay, Stephen, I wanted to test it in the “right” conditions.

lowerMemoryUsage seems to help. It doesn’t prevent the graphical artifacts completely, but it seems to reduce their occurrences. That being said, this Mac has 16GB of RAM so memory shouldn’t be an issue.

Running the 2.0.10 now, BTW.

I think the 16GB is not a big issue - I think it’s video memory that’s the problem.
With the new setting we are careful to release the whole overview grid window on each exit. This may help, but it’s rather opaque as to why the system can’t handle it - your system should have plenty of video memory also.
It’s really hard to debug this without a machine that exhibits the problem!

I’ll try to get back with some more improvements.

Hi Stephen, I still have this problem. It seems that when I click on a space in the grid, TotalSpaces (or something else) updates the contents of all the spaces before exiting the grid. Couldn’t you just exit the grid immediately instead?

Hi, I think the code does try to exit the grid immediately. But it has to wait for the space change to happen before it does.

That should be the only delay - waiting for the space to change, then the exit happens. I could maybe make a debug version that exits immediately - it looks pretty bad because the space change would be visible, but perhaps it would help us debug the performance issue.

Ah, I see. It’s a shame Mavericks introduced this problem, because it was perfect before. Anyway, if there’s anything I can do to help you solve, I’ll be glad to do it.