Une des causes les plus fréquentes des lenteurs du scrolling clavier dans une liste est le coût de la récupération des données liées à l’item sélectionné. Lorsqu’un utilisateur maintient les flèches de son clavier appuyées pour effectuer un défilement, l’élément sélectionné change très rapidement, déclenchant de nombreux et couteux appels à la source de données tels des web services ou une base.

L’idée du limiteur vient du fait que les données n’ont pas à être affichées plus rapidement que l’utilisateur ne peut les lire. On considère alors que le choix de l’utilisateur est valide après un certain temps d’inactivité (généralement court). Le projet attaché démontre cette technique appliquée à une commande dans la classe ThrottleHelper.

Les trois paramètres sont respectivements : le delegué d’exécution de la commande, le délai du limiteur, et l’action effectuée si un appel est fait avant que le délai ne se soit écoulé (en général une ré-initialisation visuelle).

Le projet attaché utilise une version simplifiée du DelegateCommand de Prism, et démontre ce pattern en Silverlight 4 et WPF 4.

Remarques

• Ce pattern est utile pour les listes, mais également pour les AutoCompleteBox : pourquoi lancer une recherche à chaque lettre tapée si votre utilisateur est un vrai dactylo ?
• Silverlight et WPF ne permettant pas l’appel de commande depuis n’importe quel évènement directement, j’utilise l’InvokeCommandAction de Blend pour appeler la commande lorsque l’évènement SelectionChanged survient
• Les Reactive Extensions (Rx) propose une implémentation de nombreux patterns asynchrones dont le limiteur (throttling)
• Pour les utilisateurs fans de la souris et sous WPF, pensez à utiliser le  scrolling différé  (à la Outlook)

Encore une fois merci à Joao pour m’avoir motiver à poster