Gridview performance problem with basic example

[Shaun]

Hello,

I am having severe performance problems with the silverlight gridview control with a very basic example.

I simply have a POCO with 7 boolean properties.   I have created a list of only 96 of these objects and bound that list to the itemssource of the gridview.    The result is a gridview which takes 3-5 seconds to load, followed by unacceptable lag.

Is the gridview really not able to handle a 96 row x 7 column grid without resorting to virtualization?

The code:

<UserControl x:Class="RadControlsSilverlightApp1.Demo"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    xmlns:telerik="http://schemas.telerik.com/2008/xaml/presentation"
    d:DesignHeight="300" d:DesignWidth="400"  DataContext="{Binding RelativeSource={RelativeSource Self}}">

    <ScrollViewer x:Name="LayoutRoot" Background="White" Height="600">
        <telerik:RadGridView x:Name="TestGrid" ItemsSource="{Binding Rows}"
                             IsReadOnly="True" ShowGroupPanel="False" IsFilteringAllowed="False"
                                 SelectionMode="Extended" SelectionUnit="Cell"
                                 ColumnWidth="100"  Width="800">
        </telerik:RadGridView>

    </ScrollViewer>
</UserControl>

public partial class Demo : UserControl
   {
       private List<RowObject> _rows;
       public List<RowObject> Rows
       {
           get
           {
               return _rows;
           }
           set { _rows = value; }
       }

       public Demo()
       {
           var rows = new List<RowObject>();
           for (int i = 0; i < 96; i++)
           {
               rows.Add(new RowObject());
           }

           Rows = rows;
           InitializeComponent();
       }
   }

   public class RowObject
   {
       public bool Monday { get; set; }
       public bool Tuesday { get; set; }
       public bool Wednesday { get; set; }
       public bool Thursday { get; set; }
       public bool Friday { get; set; }
       public bool Saturday { get; set; }
       public bool Sunday { get; set; }
   }

Note: Due to a particular requirement, I'm unable to limit the height of the gridview to allow virtualization to kick in.  I need all 96 rows to be "visible" at once.  I have noticed that doing so does improve performance slightly (though still quite bad in my opinion) but again, it's not an option for me right now.

[Vlad]

Hi,

 Can you clarify your requirement? Why you need to use the ScrollViewer and not the RadGridView scrollbars? As far as I can see you understand that in this case (measured with infinity) any UI virtual component will attempt to create all UI containers for all data items at once which is equal to severe memory and performance problems.

All the best,
Vlad
the Telerik team

[Shaun]

Hi Vlad,

Thanks for the reply.

There are a couple of reasons for the requirement.  I'm using the RadGridview to represent a daily schedule in 15 minute blocks, for a week.   Here is a partial image which should explain it:  http://i.imgur.com/NdoWwFh.jpg

Having a scrollbar on the gridview would make for an awkward user experience; The schedule is the key component of the form it is on, and it makes the most sense to view the entire schedule at once, not have it hiding behind a second scrollbar.   If I could get past that issue, there is also the custom "row headers" you can see on the left which need to scroll along with the associated data (actually just a Grid and textblocks sitting next to the grid).

As a general overview of what the UI accomplishes: the user can select a range of cells (SelectionMode="Extended" SelectionUnit="Cell") and use hot-keys to toggle cells on or off.

With the 96 rows, the control ends up being about 600 pixels wide by 2400 pixels tall.  That's not terribly big  (About 2 page lengths on my monitor), and it feels reasonable in the UI.

[Vlad]

Hi,

 Why not use our ScheduleView instead? 

All the best,
Vlad
the Telerik team