And from the output of nm 'Snapz Pro X.app/Contents/MacOS/Snapz Pro X':

U _CGRegisterScreenRefreshCallback

So it looks like they are using that. And iShowU isn't—no such line.

Peter: from what you've written here, it sounds like iShowU is very unoptimized for screencasts (I think I'm using that term correctly -- "screencast" means a movie of your screen, right?).

Yes, it does.

It's quite possible, as iShowU is the newcomer. Also, Snapz may be using the Quartz Services callback that Ken mentioned. I'll give Snapz a try and report back.

I'm taking a full-screen 30 fps screencast on my Intel Core Duo MacBook right now with no perceivable lag whatsoever, and the CPU usage for Snapz hovers around 10-15% when there's not too many changes on the screen (i.e.: you're just typing). If you're moving around windows, Snapz's CPU usage can jump to 50-60%, but that load is easily managed by today's hardware. The only time where the CPU usage gets maxed out is when Snapz is actually encoding the video into a movie file after you've finished capturing the footage, and that's not exactly surprising.

Interesting.

I'm not sure if your bandwidth argument holds up, because it seems to imply that you're writing the contents directly to disk. But if you're just caching the video in memory (and you have enough to do so), I don't think bandwidth is an issue.

With iShowU, I've used a RAM disk at times. The problem is that the Raw compressor fills my 64-MiB RAM disk in a few seconds. Over the course of an entire recording, it would probably fill the rest of my RAM too, if it could.

You might want to check out Snapz Pro X again on your Mac Pro, and compare performance to iShowU.

Snapz Pro X can *easily* handle full screen video capture of 30 fps, and it has been able to do so on most hardware for a while now, including, IIRC, G4s. (I couldn't do it on my iMac G4 800 MHz, but their developers claimed I should have been able to, and from what they told me, I was running up against a very rare bug that they could never reproduce.) I'm taking a full-screen 30 fps screencast on my Intel Core Duo MacBook right now with no perceivable lag whatsoever, and the CPU usage for Snapz hovers around 10-15% when there's not too many changes on the screen (i.e.: you're just typing). If you're moving around windows, Snapz's CPU usage can jump to 50-60%, but that load is easily managed by today's hardware. The only time where the CPU usage gets maxed out is when Snapz is actually encoding the video into a movie file after you've finished capturing the footage, and that's not exactly surprising.

I'm not sure if your bandwidth argument holds up, because it seems to imply that you're writing the contents directly to disk. But if you're just caching the video in memory (and you have enough to do so), I don't think bandwidth is an issue. I don't see why you can't take Ambrosia's approach: put off the disk writing until later when you don't need to worry about continuing to capture footage.

You might want to check out Snapz Pro X again on your Mac Pro, and compare performance to iShowU.

Not that I've tried yet.