CODEWITHSUNDEEP
c#wpfmultithreading
KBoek
KBoek

Reputation: 5975

WPF dispatcher performance (100-200 updates/sec)

In a WPF Window, I've got a line chart that plots real-time data (Quinn-Curtis RealTime chart for WPF). In short, for each new value, I call a SetCurrentValue(x, y) method, and then the UpdateDraw() method to update the chart.

The data comes in via a TCP connection in another thread. Every new value that comes in causes an DataReceived event, and its handler should plot the value to the chart and then update it. Logically, I can't call UpdateDraw() directly, since my chart is in the UI thread which is not the same thread as where the data comes in.

So I call Dispatcher.Invoke( new Action (UpdateDraw()) ) - and this works fine, well, as long as I update max. 30 times/sec. When updating more often, the Dispatcher can't keep up and the chart updated slower than the data comes in. I tested this using a single-thread situation with simulated data and without the Dispatcher there are no problems.

So, my conclusion is that the Dispatcher is too slow for this situation. I actually need to update 100-200 times/sec!

Is there a way to put a turbo on the Dispatcher, or are there other ways to solve this? Any suggestions are welcome.

Upvotes: 6

Views: 6612

Answers (4)

Pygmy
Pygmy

Reputation: 1268

I still like to know why you'd want to update a chart 200 times per second when your monitor can't even display it that fast. (Remember, normal flatscreen monitors have an update-rate of 60 fps)

What's the use of updating something 200 times per second when you can only SEE updates 60 times per second ? You might as well batch incoming data and update the chart at 60 fps since you won't be able to see the difference anyway.

If it's not just about displaying the data but you're doing something else with it - say you are monitoring it to see if it reaches a certain threshold - than I recommend splitting the system in 2 parts : one part monitoring at full speed, the other independently displaying at the maximum speed your monitor can handle : 60 fps.

So please, tell us why you want to update a ui-control more often than it can be displayed to the user.

Upvotes: 5

TomTom
TomTom

Reputation: 62093

Youre requierments are bonkers- You seriously do NOT need 100-200 updates per second, especialyl as teh screen runs at 60 updates per second normally. People wont see them anyway.

  • Enter new data into a queue.
  • Trigger a pull event on / for the dispatcher.
  • Santize data in the queue (thro out doubles, last valid wins) and put them in.l

30 updates per second are enough - people wont see a difference. I had performacne issues on some financial data under high load with a T&S until I did that - now the graph looks better.

Keep Dispatcher moves as few as you can.

Upvotes: 7

Pieter van Ginkel
Pieter van Ginkel

Reputation: 29632

An option would be to use a shared queue to communicate the data.

Where the data comes on, you push the data to the end of the queue:

lock (sharedQueue)
{
    sharedQueue.Enqueue(data);
}

On the UI thread, you find a way to read this data, e.g. using a timer:

var incomingData = new List<DataObject>();

lock (sharedQueue)
{
    while (sharedQueue.Count > 0)
        incomingData.Add(sharedQueue.Dequeue());
}

// Use the data in the incomingData list to plot.

The idea here is that you're not communicating that data is coming in. Because you have a constant stream of data, I suspect that's not a problem. I'm not saying that the exact implementation as give above is the rest, but this is about the general idea.

I'm not sure how you should check for new data, because I do not have enough insight into the details of the application; but this may be a start for you.

Upvotes: 10

Vladislav Rastrusny
Vladislav Rastrusny

Reputation: 29985

WPF drawing occurs in a separate thread. Depending on your chart complexity, your PC must have had a mega-descent video card to keep up with 100 frames per second. WPF uses Direct3D to draw everything on screen and optimizing video driver for this has been added in Vista (improved in Windows 7). So, on XP you might have troubles just because of your high data-output rate on poorly designed OS.

Despite all that, I see no reason of printing information to screen with a rate of more than 30-60 frames per second. Come on! Even FPS shooters does not require such a strong reflexes from player. Do you want to tell me, that your poor chart does? :) If by this outputting, you produce some side-effects, which are what you actually need, then it's completely different story. Tell us more about the problem then.

Upvotes: 0

Related Questions