I need real time charting (100-200ms updates) of a maximum of 20 series. After some research I settled on syncfusion because I can use the community license and at first sight it seems performant. The only drawback seems to be the sometimes lacky MVVM support.
To get a good realtime performance I found this blog post:
https://www.syncfusion.com/blogs/post/Deliver-high-performance-charts-with-Syncfusions-WPF-chart-control.aspx
I'm especially interested in the 'batch update' section because all 20 series will get updated at the same time, there's no need to rerender the chart 20 times.
An alternative seems to be this: http://help.syncfusion.com/wpf/sfchart/how-to/add-range-of-points-dynamically
I have yet to investigate the differences.
But how can I make this MVVM friendly.
Thanks for your advice!
This requirement can be achieved by accessing the SfChart control from its view(UserControl) which was initialized in the ViewModel class, to have access on SuspendNotification and ResumeNotification methods in SfChart.
Real time updates can be achieved in two ways.
By using auto-scrolling feature, to maintain a fixed amount point in view while real time update and also there is a provision to view old data through scrolling.
By removing the first record from the collection while adding new record at the end.
Demo Samples : Real_Update_Samples
Related
Scenario:
I have a TelerikAutoComplete control in one of my WPF page and the item source is a property which is filled from 35000 rows from a table in DB.
Issue :
It takes longer to retrieve the data which is hampering the load of the page.
Resolution Tried:
[EDITED]
Cause of issue was different which has been defined in answer below.
Let me know in case you need more information.
Thanks in advance.
What about: Do not load 35000 rows. That is not a sane UI if it needs all pages loaded. So, use virtualization.
I tried using the background worker, since that also derived by
dispatcher thread it still hold the page until the data is filled up
in the property.
Ah, no. Back to documentation becasue quite obviously you are not using it correctly.
The reason behind this delay was the database. We had this data coming from view which was taking whole lot of time. Changed this view into table and it made processing really quick..Sorry for late answer.
I'm running into a problem with the WPF TreeView control.
I think I ran into a memory leak issue with this control and also some performance issues.
I've prepared a simple demo solution where you can see these problems.
Download link: http://www.custom-projects.com/TreeViewMemoryAndPerformanceIssue.zip
I'm creating the tree based on some domain objects. The objects are wrapped in view models.
The number of levels is not restricted, but currently we have a maximum of 3 levels.
So, each view model can have children.
When you click on the up/down buttons of the UpDown control and don't release the mouse button you will see, that the update speed of the int value will get slower and slower and the memory consumption constantly rises.
What I'm doing: When you click on the up/down button the value is sent to the view model via data binding. In the setter I'm raising a event. Our application consists of different view models and if someone is changing data in one of them, the others are notified through these DataChanged events.
For simplicity, my demo solutions just consists of the NavigationViewModel. So it listens
for the DataChanged event and if fired, the tree is rendered.
Because we don't have a list which will always be the same (and just rows are added or removed), I'm not using a ObservableCollection. We always have to regenerate the list based on the objects the user has added/created.
Anyways, I'm adding these view models to a list and raise the NotifyPropertyChanged event
so that WPF updates the tree. Works well but the more the list is updated, the slower the application gets (and memory goes up).
I checked, that the item view models are garbage collected and they are, so I don't see
something wrong on my side. I also did some performance profiling. It looks, that the
issue is on the WPF side, because my code does not slow down. The Application.Run method
execution time rises... Strange thing.
Does anyone has an idea, why the memory is going up and never gets released and why the
performance starts to decrease the more often the TreeView updates itself?
I would appreciate any help or comment on this issue.
Thanks,
Christian
I profiled your test application using ANTS Memory Profiler and you can see that your classes 'NavigationItemBaseViewModel' and the array "NavigationItemBaseViewModel[]" are still held in memory by references, and this is getting worse with each increment.
If you slowly increment and allow the update to happen, then the references are broken and objects disposed. All good.
However, if you increment fast/continuously then you see that your references are not broken, thus the arrays are kept in memory.
The increments get slower each time because your application is having to update a lot of these view models, at increment #58 I had 172 arrays holding between them 517 NavigationItemBaseViewModel's.
Where with "normal" functionality you only have 4 arrays and 13 NavigationItemBaseViewModel's.
Hope that helps, I would recommend you profile your memory if you cannot figure out your logic where new are creating new arrays. Typically it is best to reuse arrays.
Profiler I used is here: http://www.red-gate.com/products/dotnet-development/ants-memory-profiler/index2
Hope that helps.
I was investigating lots of memory leaks in WPF and i find this tool very useful: http://www.jetbrains.com/profiler/ It has trial period of 10 days (i've just checked) so i hope you will be able to find your problem.
In case a screen of a WPF application contains lots of primitive controls, its rendering becomes sluggish. What are the recommended ways to improve the responsiveness of a WPF application in such a case, apart from adding fewer controls and using more powerful videocard?
Is there a way to somehow use offscreen buffering or something like that?
Our team was faced with problems of rendering performance. In our case we have about 400 transport units and we should render chart of every unit with a lot of details (text labels, special marks, different geometries etc.).
In first our implementations we splitted each chart into primitives and composed whole unit's chart via Binding. It was very sad expirience. UI reaction was extremely slow.
So we decided to create one UI element per each unit, and render chart with DrawingContext. Although this was much better in performance aspect, we spent about one month improving rendering.
Some advices:
Cache everything. Brushes, Colors, Geometries, Formatted Texts, Glyphs. (For example we have two classes: RenderTools and TextCache. Rendering process of each unit addresses to shared instance of both classes. So if two charts have the same text, its preparation is executed just once.)
Freeze Freezable, if you are planning to use it for a long time. Especially geometries. Complex unfreezed geometries execute HitTest extremely slow.
Choose the fastest ways of rendering of each primitive. For example, there is about 6 ways of text rendering, but the fastest is DrawingContext.DrawGlyphs.
Use profiler to discover hot spots. For example, in our project we had geometries cache and rendered appropriate of them on demand. It seemed to be, that no improvements are possible. But one day we thought what if we will render geometries one time and cache ready visuals? In our case such approach happened acceptable. Our unit's chart has just several states. When data of chart is changed, we rebuild DrawingVisual for each state and put them into cache.
Of course, this way needs some investments, it's dull and boring work, but result is awesome.
By the way: when we turned on WPF caching option (you could find link in answers), our app hung up.
I've had the same perf issue with a heavily customized datagrid since one year, and My conclusion is:
there is basically nothing you can do
on your side (without affecting your
app, i.e.: having fewer controls or
using only default styles)
The link mentioned by Jens is great but useless in your case.
The "Optimizing WPF Application Performance" link provided by NVM is almost equally useless in my experience: it just appeals to common sense and I am confident you won't learn anything extraordinary either reading. Except one thing maybe: I must say this link taught me to put as much as I can in my app's resources. Because WPF does not reinstanciate anything you put in resource, it simply reuses the same resource over and over. So put as much as you can in there (styles, brushes, templates, fonts...)
all in all, there is simply no way to make things go faster in WPF just by checking an option or turning off an other. You can just pray MS rework their rendering layer in the near future to optimize it and in the meantime, try to reduce your need for effects, customized controls and so on...
Have a look at the new (.NET 4.0) caching option. (See here.)
I have met a similar problem and want to share my thoughts and founds. The original problem is caused by a virtualized list box that displays about 25 complex controls (a grid with a text block and a few buttons inside displaying some paths )
To research the issue I used the VisualStudio Application Timeline that allows to how much time it takes to render each control and PerfView to find out what actually WPF is doing to render each control.
By default it took about 12ms to render each item. It is rather long if you need to update the list dynamically.
It is difficult to use PerfView to analyse what heppens inside since WPF renders item in the parent-child hierarchy, but I got the common understanding about internall processes.
WPF does following to render each item in the list:
Parse template using XAML reader. As far as I can see the XAML parsing is the biggest issue.
Apply styles
Apply bindings
It does not take a lot of time to apply styles and bindings.
I did following to improve performance:
Each button has its own template and it takes a lot of time to render it. I replaced Buttons with Borders. It takes about 4-5ms to render each item after that.
Move all element settings to styles. About 3ms.
Create a custom item control with a single grid in the template. I create all child elements in code and apply styles using TryFindResources method. About 2ms in the result.
After all these changes, performance looks fine but still most time is spent on loding the ListControl.Item template and the custom control template.
4. The last step: replace a ListControl with Canvas and Scrollbar controls. Now all items are created at runtime and position is calculated manually using the MeasureOverride and ArrangeOverride methods. Now it takes <1ms to render each item from which 0.5ms is spent on TextBlock rendering.
I still use styles and bindings since they do not affect performance a lot when data is changed. You can imagine that this is not a WPF solution. But I fave a few similar lists in the application and it is possible not to use templates at all.
I should start out with the disclaimer that I don't have a lot of info into this problem, but I wanted to put a feeler out to see if anyone else had this problem. I started a new job and some folks here are using Infragistics WPF datagrid. The grid was selected because of the visual flexibility, but apparently when there are large amounts of rows in the grid, things begin to perform very poorly. This is possibly due to implementation (not sure, haven't gotten into the code yet) and shouldn't be taken as a negative on the control.
Has anyone else encountered and have any advice I could pass onto the developers? Thanks in advance.
Edit*: I think introducing paging might not be an option. The grid is being used in such a capacity that it is displaying data streamed into it. So the use case is that the end user is monitoring 50-100 rows that are updating with new values intra-second (aka - think running stock tickers instead of flipping through a result set)
I'm having problems with XamDataGrid as well. Although I don't have the right version to attempt this, you might try changing to the high-performance hoverless style, and suppressing events, as described here:
http://blogs.infragistics.com/forums/p/48307/264160.aspx
The rest of the suggestions are a lot more specific and handle particular schemas and use-cases.
Here's a bit more of an overview of Infragistics optimizations:
http://help.infragistics.com/NetAdvantage/WPF/2010.3/CLR4.0/?page=xamData_Performance_Optimizations_Overview.html
I am using the Xceed DataGrid, but I recently discovered our DataGrid was binding to a View (DataGridCollectionView) and not to a datasource (DataView/DataTable).
This meant we replaced the entire view for each refresh.
By binding to a DataTable, my code now refreshes the DataGrid instantly with a few thousand rows where it use to take 1-2 seconds.
As most grids are similar. please verify how your code is binding to the data that goes into your DataGrid.
I posted some code here in case that helps.
The approach is take is to enable virtualisation - this ensure that only the information on the screen is involved in a repaint. See no problem with 100 rows being continuously updated.
In Excel, there is this feature for filtering the cells of a column.
How can I implement excel like FILTER feature in Silverlight Datagrid?
Please advice. Thanks
AJ
Good question - this is a good feature, but not one that can be implemented in 5 minutes.
You don't want to be overriding the rendering of the standard datagrid in any way (too much work), so you need to take a slightly different approach. One way to do that is to draw your own 'header' above the top of the grid - just a grid, with a border and a stackpanel will get you started. Then you need to enumerate the visible columns of the grid, and create a dropdown corresponding to each, and add that dropdown to the stackpanel. Using a simple linq statement you can get a list of the distinct values in each column. When the user selects a value from the dropdown you can then filter the grid's datasource using that value in a LINQ statement.
In reality this is probably going to be at least a week's worth of work to do properly. If you take the cost of that development and the cost of the testing, and measure that against the cost of a good component suite where they already have filtering built in (most of the major vendors do), then unless you are working for a very low hourly rate you will find it is cheaper to buy the components - it is probably safer too, as the components will be well tested and realtively bug free.
Edit (some time later): what i should also mention though is that if you only want to do this on a couple of columns then you could consider using a column header template. If you take this approach though you will also have to do things like copy the various mouse related animations or transitions that might be part of the original colunm header, just so you can keep some consistency across the top of the grid. Personally i would just go with option one and give the user the ability to filter on any of the columns.