Slowdown (Scrollbar or UI in general) in Silverlight when there are many controls

Question

I'm looking for some insight into the workings of Silverlight - at this time I suspect I need to know more about how UI event dispatching and control repainting are done to work out a solution or compromise for the following problem:

I have a large number of elements (of which I am representing as controls) on screen. Numerically it's around 300, though the exact number is dependent on the size of the browser window.

Each element will eventually display information (TextBlocks, Images) and have some mouse interactions (ToolTips, mouse events for toggling and drag and drop). At first glance it might resemble a DataGrid, but unfortunately it's not (it's an infinitely scrollable non-rectangular surface). But at the moment each element is just a user control with nothing but a Rectangle inside it.

<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);                    
}

---

Creating 300 of these controls and dropping them onto a Canvas (or Grid) is slow - 4 seconds to complete. However since this operation is rarely done, I'm not as concerned about it as the next problem.

Once the controls are placed CPU is normal (0%), but attempting to use an unrelated ScrollBar (a ScrollBar primative with no events) shows a lot of lag - the scrolbar thumb struggles to keep up with the mouse. If I increase/decrease the number of elements, the scrollbar lag changes accordingly.

---

Under the assumption that the canvas element (which normally allows elements to overflow) is doing some clipping calculations I tried both defining a clipping rectangle for the canvas, moving the scrollbar entirely away the canvas (into a different layout tree), and changing from a canvas to a grid (with all 300 elements just sitting in the center overlapping). I also testing changing the elements Visiblity to Collasped, with no effect.

I've also tried substituting the elements - creating just a rectangle or an image reduces the slowdown, but only to the degree I'd expect from there being fewer elements on the tree (MyElement being 3 controls, UserControl, Grid and Rectangle, instead of 1).

Under the assumption that some Find method was having to transverse all 300 of my elements before getting to the scrollbar, I tried to change the order of declaration in the XAML file, with no luck.

And finally I've tried setting IsHitTestVisible and IsEnabled to false on the elements and the entire Canvas, to no effect.

---

So far as I can tell I have a large but entirely reasonable number of static controls, that are not using any CPU normally, yet when I try interacting with an unrelated ScrollBar, they create some kind of traffic jam in the UI or rendering pipeline.

Any ideas where that is or how to solve it?

EDIT: Initial cause has been found, see below. (Added themes tag)

Answer 1

Through trial and error I've finally found the factor responsible.

I'm using the Theming system from the Silverlight Toolkit. As I create a lot of controls dynamically ("windows" and "dialogs"), the theme has ApplyMode="Auto", in which controls automatically have the theme styles applied.

For whatever reason dragging the thumb of the scrollbar control is triggering this constantly, causing the style information of all those controls to be updated, regardless of where they are or if they are even visible.

Unfortunately I don't see any quick solution for just turning that off as dynamical controls are everywhere. What I've tried to do is change ApplyMode to one time only for just the ScrollBar, however this doesn't seem to be working. My best guess is that the scrollbar is dynamically creating some control for every change - any insight into this?