10.4: A programmatic fix for an Exposé slowdown

There's been some discussion on Mac forums about an Exposé slowdown in 10.4. The slowdown is allegedly due to the new feature introduced in Tiger called Automated Beam Synchronization. Using Quartz Debug from Developer Tools it is possible to temporarily disable Beam Sync.

If you're interested in more permanently disabling Beam Sync, read on...

This thread at CocoaBuilder.com demonstrates code for programmatic disabling of Beam Sync:


extern void CGSSetDebugOptions(int);
extern void CGSDeferredUpdates(int);

typedef enum {
  disableBeamSync = 0,
  automaticBeamSync = 1,
  forcedBeamSyncMode = 2
} beamSyncMode;

beamSyncOption mode = disableBeamSync;

CGSSetDebugOptions(mode ? 0 : 0x08000000);
CGSDeferredUpdates(mode);

It needs to be linked against QuartzCore. If you rather not deal with coding, you can use a simple command line tool called beamsync. Running beamsync with the -d option disables; -a makes automatic, and -f forces beam synchronization. The source code is available as well. Note that both the tool and the code rely on the undocumented API, which is a subject to change in the future Tiger upgrades. It's provided as is; use at your own risk.

Here's a simple method to see if disabling beam sync increases the fps on your system:

Follow the steps in the original hint to run Quartz Debug, but don't disable beam sync right away.
From the Tools menu, enable Frame Meter.
Grab any window on the screen (the Quartz Debug window will do) and "shake" it with a mouse. You'll see the FPS meter go up. On my laptop with Beam Sync enabled, it only goes up to 35 fps.
Now disable Beam Sync and repeat the shaking. The fps should now be around 60! Amazing

[robg adds: With the original hint, I noted that I hadn't seen any slowdown. But using the above method, it's clear that the FPS is capped at 35 when beam sync is enabled. I installed the beamsync app and have set it to disabled, and now the FPS is floating closer to 60.]

Hints by Topic

10.4: A programmatic fix for an Exposé slowdown | 10 comments | Create New Account

Click here to return to the '10.4: A programmatic fix for an Exposé slowdown' hint

The following comments are owned by whoever posted them. This site is not responsible for what they say.

10.4: A programmatic fix for an Exposé slowdown
Authored by: slacks on Jul 06, '05 11:09:28AM

My frame rate went up to 60, but does anyones window break up around the edges when they move them around?

10.4: A programmatic fix for an Exposé slowdown
Authored by: MoparShaha on Jul 06, '05 03:50:23PM

Yes, this happens to me as well. There seems to be a horizontal redraw guide in the middle of the screen. Anytime I move a window and it crosses this guide, the guide becomes visible because the window contents become distorted.

Isn't tearing exactly what Beam Sync prevents?
Authored by: Makosuke on Jul 06, '05 04:53:42PM

Perhaps I'm misunderstanding the terminology here, but the "breakup" described in the post above appears to be describing tearing (I think that's the common term), an effect that happens, basically, when the monitor switches from drawing one frame to the next in the middle of a screen refresh--the top half of the image is one frame behind the bottom, basically.

I'm assuming that "Beam Sync" prevents exactly this--the same as the synch that can be done in some (most?) 3D games to eliminate tearing, so of course turning beam sync off would bring the tearing back.

Funny, because the screen redraw synching is probably my single favorite feature of Tiger, so disabling it seems crazy. It makes watching videos onscreen or dragging around windows vastly more attractive on an LCD monitor, where tearing problems (particularly with fullscreen video) were nasty with 10.3 and earlier.

Isn't tearing exactly what Beam Sync prevents?
Authored by: slacks on Jul 06, '05 06:18:31PM

Thanks, I appreciate the informative response. The word "tearing" escaped me while I was posting. You make a good argument for leaving Beam Sync enabled. I do remember playing full screen videos in 10.3 and witnessing some tearing. I don't however remember window tearing being that drastic though. At least nothing compared to the tearing I used to see in X-windows under Linux, or after I turned off Beam Sync as described in the hint. Also I thought Double Buffering helped prevent window tearing?

Isn't tearing exactly what Beam Sync prevents?
Authored by: Dirk! on Jul 07, '05 05:33:07AM

Yes, I second: beamsync prevents tearing. Double buffering only prevents tearing if the buffer is copied to the screen in sync with the refresh rate.

Did anyone notice that "Quartz Debug" has an menu item to enable/disable "beam sync". So why use the command line tool?

Dirk

Isn't tearing exactly what Beam Sync prevents?
Authored by: slacks on Jul 07, '05 01:29:21PM

Using Quartz Debug was part of the original hint. Downside was you had to force quit the program in order for the settings to stick, otherwise they would revert.

10.4: A programmatic fix for an Exposé slowdown
Authored by: Arturia on Jul 07, '05 01:16:11AM

Pretty cool, thank you.
But how do you work this application, beamsync?

I've got it installed in /usr/bin/ but I'm getting a "command not found" when I try to run it with sudo beamsync -d
I also tried with cd /usr/bin/ then sudo beamsync -d

to no avail

TIA

10.4: A programmatic fix for an Exposé slowdown
Authored by: Arturia on Jul 07, '05 01:29:52AM

Ok sorry... replying to myself

I fixed permissions on beamsync and all went well.

Thanks again :-)

10.4: A programmatic fix for an Exposé slowdown
Authored by: unagi on Jul 08, '05 03:51:33AM

found the defaults to change: use this console cmd:

sudo defaults write /Library/Preferences/com.apple.windowserver Compositor -dict deferredUpdates 0 You can verify this by opening /Library/Preferences/com.apple.windowserver in Property List Editor and expand "Compositor"

Open Quartz Debug and reveal the Beamsync tools. change the setting.

Reopen /Library/Preferences/com.apple.windowserver and expand Compositor to see the new setting.

0 = disable beamsync

1 = Auto beamsync

2 = force beamsync

Of course, YMMV.

Enjoy!

[ Reply to This | # ]

One disadvantage of turning off beamsync
Authored by: jayjanssen on Oct 23, '05 10:37:09AM

For those wondering about what effect turning off beamsync is, I've found the 'Cube' transition effect while using 'Desktop Manager' tends to be slightly degraded which beamsync off. I believe this is the same effect used by the quick user switching, but I haven't played with that.

Certainly the trade-off of a much smoother expose is worth it.

Hint Options

Search

From our Sponsor...

Latest Mountain Lion Hints

User Functions

What's New:

Hints

Comments last 2 days

Links last 2 weeks

What's New in the Forums?

Hints by Topic

News from Macworld

From Our Sponsors