One of the most frequent cause of slow scrolling lists is the cost of loading the data related to the currently selected item/row. When a user holds his arrow keys down to scroll, the selected item changes very quickly, potentially triggering a large amount of expensive queries to the data source (wether it be web services or a database).

The general idea behind the throttling technique is that in a master-detail scenario there is no reason to update the detail view faster than the user can actually read it. Therefore we consider that the user‘s choice is applied only after stopping on a particular item for a certain amount time. The attached project implements this technique in the ThrottleHelper class which is applied to a command.

The three parameters are, respectively, the command execution delegate, the throttling delay, and the action that should be performed if a call is made before the delay is expired (usually some kind of visual reset).

The attached sample project uses a simplified version of the DelegateCommand from Prism, and demonstrates the pattern on both Silverlight 4 and WPF 4.

Remarks

• Throttling is not only nice for master/details scenarios, it is also very useful for autocomplete boxes : why start searching for every letter with a fast typist ?
• Since Silverlight or WPF do not allow commands to be triggered from events directly, I used Blend’s InvokeCommandAction to call the command when the SelectionChanged event fires
• The Reactive Extensions (Rx) feature a rich set of asynchronous patterns implementations, including throttling
• For mice savvy users on WPF, consider leveraging the deferred scrolling feature (à la Outlook)

Once again, thanks to Joao for motivating me into posting this !