In Emplode, I believe they have a background thread that updates the soup view periodically (or the thread is triggered when an update occurs).

Something like that. It's a bit cheesy, really. We set a timer for 2 seconds. Since timers are really low priority, we don't see the WM_TIMER message until we've stopped doing things.

In the handler, we kill the timer and trigger an incremental update of the tree. This is done using a variation of a mark-and-sweep strategy.

I might lengthen the delay, because 2 seconds seems to be exactly in line with the speed with which I switch to and from applications, which means I always have to wait for the update to finish.

This isn't such a problem in release builds, but I generally run with a debug build, and walking the tree to do an update can take up to 12-15 seconds.

I considered doing this on a background thread, but then we get into locking issues, and this solution is perfectly usable.