RealTime DataGrid - Is anyone else here doing this?

Nov 3, 2008 at 3:12 PM
Hi All,

I'm working on a project where I keep the data in the WPF datagrid updated by polling a database for newly added or changed records.

Is anyone else here doing this?  It would be cool to start a discussion about what strategies people are using for this.

Right now I basically poll on the database for changes on a background thread, then pass any updates to the UI thread so that it can merge these changes into an observable collection that the grid is tied to.

I need to do these updates while the user could be dropping an item on the grid, or performing some other action on the grid.

Is anyone else working on something similar?
Nov 3, 2008 at 4:58 PM
Yes, trying the same, currently polling on a background thread, and just updating the property that the itemsource is bound to. Check out this thread to see a link to a sample sln. I'm not sure if this approch will make it to the end, but you could have a look.

Feb 22, 2010 at 5:46 PM

I am having difficulty using the chart in this toolkit for real time data visualization.

As an example, I have an area chart that has seven series in it. Each series uses an in-memory collection for its source of data; each collection has about 22 elements that are X/Y coordinates. This is small set of data by almost any standard.

When I update the data on just one series at the rate of once-per-second by setting the series’ ItemSource property, my CPU usage for the application rises from 1% to an average of 12-15%, and occasionally spikes to the 20s. If I set all seven series in a single method that is called at once-per-second, I see an average CPU usage of 60-65% with spikes as in the 90s. Reducing the interval to as little as once every five seconds didn't seem make much impact on performance either.

I have verified through code isolation that setting the ItemSource property is what is bogging down the CPU. I have also used the WPF Performance Suite (Wndows SDK)  to verify that it is in fact the chart control that is responsible for the usage during that time.

Based on this, I don’t see how it could be used in a lot of “real time visualization” scenarios such as instrumentation applications—especially where larger sets of data might be required, multiple charts per screen, and/or other applications need to be running in the background.