Je cherche un aperçu du fonctionnement de Silverlight - en ce moment je soupçonne que j'ai besoin d'en savoir plus sur la façon dont l'événement et le contrôle sont repeints fait pour élaborer une solution ou un compromis pour le problème suivant:Ralentissement (barre de défilement ou interface en général) dans Silverlight quand il y a beaucoup de contrôles
J'ai un grand nombre d'éléments (dont je représente comme des contrôles) sur l'écran. Numériquement c'est autour de , bien que le nombre exact dépende de la taille de la fenêtre du navigateur. Chaque élément affichera éventuellement des informations (TextBlocks, Images) et aura quelques interactions avec la souris (info-bulles, événements de souris pour basculer et glisser-déposer). À première vue, il pourrait ressembler à un DataGrid, mais malheureusement ce n'est pas le cas (c'est une surface non rectangulaire à défilement infini). Mais à l'heure actuelle, chaque élément est juste un contrôle d'utilisateur avec rien mais un rectangle à l'intérieur.
<UserControl x:Class="MyElement" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Width="49" Height="49">
<Grid>
<Rectangle x:Name="Border" Stroke="Black" Fill="White" />
</Grid>
</UserControl>
for (int i = 0; i < elementsRequired; i++)
{
var item = new MyElement();
// Set Canvas.LeftProperty and Canvas.TopProperty to a unique position
ElementsArea.Children.Add(item);
}
Création 300 de ces contrôles et les déposer sur une toile (ou grille) est lente - 4 secondes. Cependant, comme cette opération est rarement effectuée, je ne m'inquiète pas autant que le prochain problème. Une fois les contrôles placés, le CPU est normal (0%), mais tenter d'utiliser un ScrollBar sans rapport (un ScrollBar primitif sans événement) montre beaucoup de retard - le pouce du scrolbar a du mal à suivre la souris. Si j'augmente/diminue le nombre d'éléments, le décalage de la barre de défilement change en conséquence.
En supposant que l'élément de toile (ce qui permet normalement des éléments de débordement) fait des calculs de découpage que j'ai essayé à la fois la définition d'un rectangle de découpage pour la toile, en déplaçant la barre de défilement tout de suite la toile (dans une autre mise en page arbre), et en passant d'une toile à une grille (avec tous les 300 éléments juste assis au centre chevauchement). J'ai également testé en changeant les éléments Visiblity à Collasped, sans effet. J'ai également essayé de substituer les éléments - en créant juste un rectangle ou une image réduit le ralentissement, mais seulement dans la mesure où je m'attendrais à ce qu'il y ait moins d'éléments sur l'arbre (MyElement étant 3 contrôles, UserControl, Grid et Rectangle, au lieu de 1). Sous l'hypothèse qu'une certaine méthode de Find devait traverser tous les 300 de mes éléments avant d'arriver à la barre de défilement, j'ai essayé de changer l'ordre de déclaration dans le fichier XAML, sans succès.
Et enfin j'ai essayé de définir IsHitTestVisible et IsEnabled sur false sur les éléments et l'ensemble du Canvas, sans aucun effet.
Pour autant que je peux dire que je suis un grand, mais tout nombre raisonnable de contrôles statiques, qui n'utilisent pas une CPU normalement, mais lorsque je tente d'interagir avec un ScrollBar sans rapport, ils créent une sorte de embouteillage dans l'interface utilisateur ou le pipeline de rendu.
Des idées où c'est ou comment le résoudre?
EDIT: La cause initiale a été trouvée, voir ci-dessous.(Ajout d'une balise de thèmes)