I have a window using a WPF ListView/GridView bound to an ObservableCollection. The performance is utterly horrific. The application chokes trying to load 300-400 items and CPU usage spikes each time an item is added/removed/modified. Profiling doesn't reveal anything obvious.
Anyone have any suggestions?
Check these properties out:
VirtualizingStackPanel.IsVirtualizing="True"
VirtualizingStackPanel.VirtualizationMode="Recycling"
ScrollViewer.IsDeferredScrollingEnabled="True"
You need to virtualize your ListView's ItemSource as explained in this article: WPF: Data Virtualization on CodeProject by Paul McClean
First guess, are you making use of complex data templates for each ListViewItem? This might be anything from lots of images, to (old) BitmapEffects, to even lazy-loaded properties that fetch data on demand from a database (which may cause you to perform many db calls to render each visual, depending on how your data model works).
Second guess, is the list itself able to run its load/add/modified/removed routines quickly (meaning the problem occurs when rendering the data), or does the list itself do those jobs slowly (indicating the list is having some kind of issue).
have you tried virtualization as recommended in this question??
WPF ListView Very Slow Performance - Why? (ElementHost, or Other Reason?)
And the obvious one, make sure you have upgraded to .net 3.5 SP1, there were a lot of performance gains there.
Also it may be worth looking into the WPF datagridview control as a lot of the performance work in .net 3.5 SP1 were so the datagridview would have good performance on large datasets.
http://wpf.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=25047
I had similar problems. Setting MaxHeight to a value larger than the ListView's actual height solved it instantly for me, thanks to this answer here, but I still fail to understand how it worked.
Related
I'd like to create a Winform app (Mono support would be a huge plus) to display a grid of rapidly updating numbers, while not running into redraw problems while scrolling.
From searching around I've found:
Telerik GridView
which seems to be exactly what I want. Is the Telerik path the way to go? Or is the capability available within the standard .NET tool set? If so, which widgets should I be looking at to implement such an application?
Thanks in advance for your help!
All the Grid components from vendors are going to have performance issues if you change the attached values very very quickly. So if you need high performance you really need to create your own. If you are concerned only about flicker and the update does not need to be amazing quick then you will be fine with Telerik or indeed any other vendors Grid component.
You could consider implementing Virtual Mode on the Telerik RadGridView to overcome any performance issues you might encounter.
The demo application included with the controls contains an example of a rapidly updating grid. Although its just a small demo, if you resize the window to be smaller the scrollbar will appear and you can scroll without any redraw issues. You can access the demo under GridView -> Performance -> High Refresh.
Unfortunately, the Telerik WinForms controls aren't compatible with mono.
Im working on a middle size project, using WPF. Need DataGrid, suitable for the client: fast, customizable, beautiful. Which component suite do you suggest from your practice?(for example Devexpress's, telerik's, Infragistics's and etc)
I have used Telerik data grid in the past and it seemed to have the least hastles for me compared to others I have had a look at.
However I can pretty much put my money on it that someone else would feel that Telerik's control wasn't great and that Infragistics was better etc. - so I suggest that you maybe download the trials and test them for your specific scenario.
"Fast, customizable, beautiful." - try Xceed's (I work there), there's a no-install XBAP demo. Also supports asynchronous data virtualization and smooth scrolling and other stuff no other datagrid does.
Xceed DataGrid for WPF main page
XBAP demos page
I've been evaluating Xceed for a few weeks now and while it is powerful it's dog slow when placed in a tab control switching between tabs. 30 seconds to open a tab on a large data set. The forum on their website seems to suggest this is a known problem without resolution. Shame as in other aspects it appears to do a good job.
I have some performance related questions about SL Enterprise app development.
-We have 10.000 rows binding to an ItemsSource control. (A total of 100.000+ UIElements when databound)
Q1.How to do this binding in another thread? Because Silverlight gets stuck while the binding happens.
Q2.Any other ways to do this that you suggest with the same visual flexibility like we have in an ItemsControl.
-We are pulling a total of 60MB (unzipped binary serialized XML) data from server and letting our SL users use it for a period of 20 minutes.
Q1.We have some memory leaks and getting hard time to figure out what’s staying in the memory? Do we have a tool to show this?
According to our latest test UIElements are the ones filling the memory. We have 5 nested Itemscontrols, tracking a lot of “loaded” events of inner control in order to fill the appropriate values with calculations. As far as I see virtualization is not working on Items control.
Thanks for all your time.
If you are using the DataGrid, Virtualization should be on by default.
Pulling that much data at one time might also pose a problem. I'd try to find some sort of solution that involves server-side paging.
EDIT:
Just saw that you are using an ItemsControl. The biggest performance boost you'll see (before even getting server paging to work) would be to get virtualization working. Here's a good article about doing it with a generalized ItemsControl (It also addresses your problem with events not firing correctly):
http://blogs.claritycon.com/blogs/lee_roth/archive/2009/09/16/custom-panels-in-silverlight-wpf-part-4-virtualization.aspx
In our current WinForms app, we are displaying millions of records in ListView, using virtualization. Rows are loaded from DB as they are requested. This works well, with good performance.
This is a showstopper for migrating to WPF for us. We need data virtualization in a ListView, like WinForms 2.0 has.
Do you know a decent third-party control, or a relatively easy way of doing it with built-in controls? It doesn't need to be a DataGrid, a simple ListView will suffice.
Note, I'm note talking about UI virtualization, it's data virtualization.
The article WPF Data Virtualization should be exactly what you are looking for, I just implemented it quite easily, and it works.
Xceed DataGrid for WPF has data virtualization support.
This is the description for the Ultimate ListBox for WPF from Xceed:
Intelligent virtualized background data retrieval:
Automatic data retrieval only gets records from the remote data source if they are visible (data virtualization). This greatly reduces the amount of data to be transferred, which increases the perceived speed of the listbox. Also reduces strain on the server.
Just add following properties in your listview declaration in XAML.
<ListView
VirtualizingPanel.IsVirtualizing="True"
VirtualizingPanel.IsVirtualizingWhenGrouping="True"
VirtualizingPanel.VirtualizationMode="Recycling"
ScrollViewer.IsDeferredScrollingEnabled="True" >
</ListView>
I have seen a lot of discussions going on and people asking about DataGrid for WPF and complaining about Microsoft for not having one with their WPF framework till date. We know that WPF is a great UI technology and have the Concept of ItemsControl,DataTemplate, etc,etc to make great UX. Even WPF has got a more closely matching control- ListView, which can be easily templated to give better UX than a traditional Datagrid like display. And I would say a readymade DataGrid control will kill or hide a lot of creativity and it surely will decrease the innovations in User Experience field.
So what is your opinion about the need of DataGrid in WPF as a Framework component? If you feel it is necessary then is it just because the world is so used to the DatGrid way of data display for many years?
Some other threads having the discussion about DatGrid are here and here
Link to WPF ToolKit - Latest WPF DatGrid
DataGrids are excellent for displaying large amounts of tabular data bound to a backing store.
But what happened in the WinForms world was that people often used them for everything that required a multi-element scrolling list. Souped-up third-party DataGrids soon became available that allowed columns and fields to contain buttons and ComboBoxes and icons, etc.
The DataGrid became a workhorse because there was a need for something it could be coaxed into behaving like. Similar happened to DataTables before generic collections came along--and when you're using lots of DataTables, presenting it in the UI with a DataGrid is the path of least resistance.
I think that when WPF came out, a lot of programmers like me were still thinking in this fashion, and sought out WPF ports of the DataGrid concept.
Can't think of a better control to display tabular data, especially in business apps where you don't want to reinvent the wheel by templating/developing a (Headered)ItemsControl to make it behave like the good old DGV. I'm sure you saw this.
Nobody is disputing that you can make a DataGrid control in WPF yourself. The same can probably be said about WinForms, although it would be more difficult. I've implemented some functionality with ListView - presenting tabular data is easy, you could even say it's well supported. However, the amount of code, manually written code, needed to make an editing ListView is enormous.
The business applications usually require editing of many tables, and you don't want to be creative, you want to be quick. That's why DataGrid is needed in my opinion.
Yes DataGrids will never go away as essential business UI components. People love their spreadsheets and we want to share in that love!
Note that MS are shipping these extra controls - they have created the WPF Toolkit on CodePlex to provide a fast-turnaround, open-source style of deployment.
It already includes a DataGrid and Calendar.
Yes it is!
Among many other controls that ms failed to deliver. (Datepicker, NumericControl)
MS should first give us the tools to get the job done, that is the least i expect from a programming enviroment with the hype of wpf.
It is essential, but you can achieve nearly the same effect with a ListView that is using a GridView, can't you?
After working with WPF for about 2 years now. I would say that a DataGrid is really just a glorified ListBox (since [almost] everything in WPF is styleless).
One could style a ListBox to take an Entity of some sort and show a "record" control for each entry. Depending on how flexible these are made, they could automatically adjust based on the entity passed.