¶Please stop with the background tasks
My current technique for testing A/V sync in VirtualDub is to hook my capture device up to a PlayStation 2 and then play a game of Guitar Hero 2 or Rock Band through my laptop. How poorly I do indicates how much lag there is on the real-time display. (If I do well, it means that there is possibly also a problem with the universe.) I can then play back the capture file to see how well the resync engine performs and to compare VirtualDub's preview mode against DirectShow sync. And I get to hear some decent music, too.
Imagine my surprise when I started playing the capture AVI file and Media Player Classic started stuttering horribly.
My first instinct was that maybe something had gone horribly wrong with the interleaving code or that my disk was terribly fragmented, but after bringing up FileMon it was quickly apparent that the problem was actually Visual Studio. Specifically, Visual Studio had suddenly decided that it wanted to rebuild the Intellisense database for VirtualDub, and had started thrashing the disk, which in turn completely screwed my video playback. So then I had to wait a few moments while Visual Studio took its sweet time until I could actually play video again.
I'm now of the opinion that running tasks in the background is a bad idea and contributes to the opinion that computers are slow and unpredictable. In this case, the Visual Studio programmers got the idea that Intellisense could be made low impact and "invisible" by running it as a low priority background thread, which ignores the problem that it still drains a huge amount of I/O bandwidth on the hard disk. This isn't the first time the Visual Studio team has done something like this -- I love it when the .NET Framework updates and suddenly a lot of CPU is taken up by "background" NGEN tasks for minutes at a time. If everyone did this, computers would be stuck at 100% CPU for hours at a time with no apparent reason.
We've now gotten to the point where computers are fast enough to perform many everyday computing tasks much faster than necessary, which unfortunately has given rise to the opinion that we don't need efficient code anymore. While it's true that there's no need to make a window come up in 0.5ms when it currently comes up in 5ms, I think the recent trend toward low-power, quieter, and lighter-weight devices is providing a new reason for efficient code. For many programs, it'll no longer be about making the program run faster, but to make it run more efficiently, letting the CPU and GPU idle more, allowing the hard drive and fans to spin down, and prolonging battery life on laptops. This is nothing new to people who worked on older platforms or on mobile devices, but this kind of thinking isn't as common in the desktop world. Heck, in the DOS days there wasn't even a way to idle the CPU... well, unless you cared about Windows 3.1 and issued the obscure INT 2F/AX=1607/BX=0018.
Now, whether people will actually care about this, I don't know. The current trend on Windows toward rendering everything in a UI every frame and/or in software rendering isn't heartening, and "efficient operation for prolonged battery life" isn't something I normally see as a bullet point in program advertisements. With the rate of hardware advancement slowing and the rise of lower powered "netbook" devices like the Asus Eee, though, I'm hoping to see a bit of a reversal here. I don't need my laptop to run hotter than it already does.