How to handle idle time processing: When idle is not really idle

Did you know that on fast machine idle time processing can kick in even if from you point of view application is not really idle? Take, for example, MFC. It calls OnIdle when application message queue becomes empty. Now, imagine that you are typing something. On fast machine application message queue may become empty between keystrokes since fast box can finish processing of the keystroke well before you type the next character. In fact, even if you press ahd hold a key, forcing fast repeating character input, application still may hit idle.

If idle time processing cannot be split into small chunks, it entering idle when user is, in fact, still typing, may really hurt application UI responsiveness. For example, VS HTML editor performs parse at idle time and we really don't want this to happen when you are still typing since parser pass is an atomic action at least in the current version.

So we really must ensure that idle is really idle. The best way to achieve that, is to call GetLastInputInfo  Win32 API and then check if difference between dwTime field in the LASTINPUTINFO structure and the current tick count (see GetTickCount) is large enough (like, 500ms or so) before you execute any idle time code. GetLastInputInfo is avaialble on Windows 2000 and higher.

Here is some old, but still relevant MSJ article on the subject.