Partager via

Wireless mouse, HTML editor and idle time processing

  • Article

Several people reported issues when toolbox, validation and/or server code intellisense do not work reliably on some machines. Turned our that the issue is related to wireless mouse driver broadcasting messages and preventing Visual Studio IDE from processing idle time. Rick Strahl blogged about this here and here. The problem also manifests itself in the OS when screen saver never activates and/or machine never goes to sleep. There are several KB articles on the issue, here is a combined one: https://support.microsoft.com/kb/555920

So why HTML editor seems to be more sensitive? And why IDE needs idle time processing at all? Why not use background threads, for example?

Application enters idle state when there are no more messages in the queue. On a fast machine this may happen even between keystrokes: I blogged about it here. Since we do not want idle time processing to affect typing, idle time processing is delayed a bit in order to avoid starting idle process between keystrokes. Different editors and components in VS may choose different delays depending on length of the idle time operation. For example, if operation is only going to take 100ms there is little reason to delay it at all. On the other hand, if operation is going to take a second, then we need to be sure that user activity has stopped. However, if a new message comes before delay interval expires, idle time never happens. Thus, if one editor delays idle processing by 200ms and another delays by 1000ms while wireless mouse driver broadcasts messages every 500ms, then former editor won't be affected while latter definitely will be.

Why do we need idle processing at all? Some operations, like HTML validation,  are lengthy and we don't want to block the UI for long. Therefore validation is running on idle, processing elements in chunks and yielding if there is a keyboard or mouse activity. Ideally operations like this should be happening in a background thread. Unfortunately, not all operations can be moved to background threads since not all interfaces in VS are thread safe and thus must be called in the context of the main (UI) thread.

In VS 2008 HTML editor some additional operations were added to idle loop (like toolbox building) which, I guess, made the loop too heavy. We are working on structuring operations better and moving certain parts back to the main code path in the next service pack. We are also looking into employing more background thread processing in future releases since this will allow us to avoid idle processing altogether.

Comments