I haven't used it yet, but my understanding is that WPF in .NET 3.0
provides a good, high-level animation API that should allow you to not
need to worry about those kinds of specifics.

If you want to do the animation explicitly in .NET without WPF, I think
you may find that the simplest method of maintaining an off-screen
Bitmap into which you do all your drawing and which is then copied to
the screen may work best.  If you do it that way, you _might_ want to
track what areas have changed so that only those areas have to be
erased, redrawn, and then copied to the screen, as you mention above.

However -- and I realize this seems a little counter-intuitive -- my
experience has been that your time is better spent ensuring that you can
redraw _everything_ each frame while maintaining sufficient performance,
and then don't worry about minimizing what you redraw.

The reason being that changes in frame rate can be just as problematic
as low frame rate, and so if your code only performs well when it
doesn't have a lot of work to do, it will bog down noticeably during
those moments when a lot of things are changing at once.  Drawing,
especially off-screen drawing, is actually very fast these days, and I
think that the exact techniques you're mentioning aren't as relevant as
they once were.

It does depend on exactly what you're animating, but I'd say you should
ignore the partial-redraw issue until you've got a basic implementation,
and are actually seeing some performance problem that mandates that, and
which you aren't able to solve through a better drawing algorithm.

Pete