This is an interesting discussion, because you made a scientific study of the issue, and provide a link to an interesting program, which also answers questions in another thread. Ie. about capturing both video and sound in a synchronized way. So far, the best answer is to use Fraps, which is not free and not perfect.
Have you used Krut? Does it support such resolution with satisfying results? I suggest to include it in your study (and to use a lighter color for the red, it hurts my eyes... ), so we can see what is possible in the domain.

Indeed, so far, I suggested that causes of the slow down is the compression algorithm and the disk storage. BTW, isn't TGA the recommended format? It is the uncompressed format, leading to big disk consumption. Ah, I see it now in the hard-to-read (for my old eyes/CRT screen) red area... It has no compression cost but this can be ruined by slow disks, which is less an issue today. And one can use SSD disks or even a simple (but fast) USB memory key for fast storage.
I also suggested that sketch capture is often incompatible with real-time (in practice of Processing, at least) and that this real-time requirement is often not necessary when making a movie. But that's not always true, eg. when sketch depends on music play or similar.

Looking at Krut, I see it uses the JMF (Java Media Framework) library, which is interesting because it gets rid of QuickTime (I now dislike having to install the latter, and even more to update it regularly. I am not fond of Apple softwares on Windows...).
From what I read, it saves Jpeg files and then assemble them, unaltered, into a .mov file. This strategy can lead to bigger files (Mpeg can encode only the differences between frames, leading to better compression) but more faithful ones, allowing less loss when converting to other formats (and there are tools like FFMPEG to do the conversion).
I wonder what quality level it uses for the Jpeg format? Are there artifacts or are the images crisp? Since it is primarily a screencast tool, I suppose it should use a low compression ratio.

Last note: if Krut works well, why not take the route of skipping saveFrame and using it directly? As an external tool. Not sure if it is interesting to include it in Processing. Too much features can bloat Processing which isn't small already. Recommending tools is another interesting way, because people can try and use alternatives.

Lot of good points. Since this is officially a discussion now, let me chime in again.

It is indeed possible - and perhaps in the end necessary - to use other programs for capturing the sketch output. But in my opinion the most ideal solution would be if this could be done from within Processing. Luckily there are alternatives available if the conclusion is that it can't be done from within Processing. However is that the conclusion that we can make already?

In the past I've relied on TGA or didn't need realtime sketches when creating the movie. However as pointed out this is starting to become less acceptable, because it's a dissonant in a more and more professional quality landscape. And by that I'm referring to both the quality and capabilities of Processing and libraries such as Toxiclibs, GLGraphics, Proscene and controlP5. For example I've just ported some code to GLGraphics making the whole sketch run fast in realtime and Proscene's cameras depend on this (they break in non-realtime, see this thread). Given that everything runs fine, it really feels like the area of sketch capture is falling behind. I understand that adding functionality like this to Processing can create bloat and that not everyone works in these resolutions and needs functionality like this. But besides libraries, Processing can also includes contributed tools. This would be a perfect subject for such a contributed tool.

Because of my need to capture a high res, high speed sketch I've looked at these kind of alternatives you mention. There are a lot. Fraps is indeed the top choice for OPENGL content. I thought I should mention Krut because it's java. My first impressions are that performance-wise Krut may also not be the perfect solution (pro: uses threads, streams to hd buffer, contra: takes system resources during capture, takes a lot of time to convert afterwards). Krut is also somewhat tedious to use with regard to defining the capture area and the setting changes not being saved. The jpeg quality is a setting too, which is 0.75 by default. But Krut and it's techniques are an example of what could be done within java. Or given the contra's perhaps also what can't be done within java? Maybe Krut's Robot screenCapture is not the best, but some direct OPENGL stuff would be better? Anyway, Fraps seems to be much more powerful, lightweight and works well with OPENGL. I've also installed this program. I will have to run more tests but it seems currently the best solution for my situation. The only disadvantage is that it can only save to AVI while I personally prefer Quicktime. For now I will probably be using Fraps for capturing sketch output under these conditions.

So some of the points / question that arise in this discussion are:

• Is it technically possible to capture high resolution (OPENGL) sketch output in Java and/or Processing?
  
• If so, would sketchCapture be a great addition - for example as a contributed tool - to Processing?
• If (currently) not, do you use external programs to capture sketch output? Which ones would you recommend?
  

I'll be abroad for a couple of days, but after that l'll be able to continue the discussion and testing.

I've worked on this before, although I haven't tried it with the latest alpha release yet. This tool has maybe never been entirely reliable with OpenGL and stuff like using the draw registered method. I consider it not fully developed and tested.

I mentioned one way to reduce total file size on disk while recording in the last post. I think it might be possible to somehow work inside of zip files on the fly as well (?).

It might be interesting to try to save the image data in a database as database systems are designed to reduce IO latency.