what would be the max event updates/sec to a C# WPF app I should allow

Question

I'm going to have quite a few event updates to a C# WPF GUI coming through from a class library I have - I'm thinking I should probably throttle the number of events that can get through per second, so:

1) Any rule of thumb re how many UI changes update events one should allow through per second? (e.g 10 per seconds say) - in my case they'll be driving a change to values in a bar graph (i.e. so bars will go up/down in real time)

2) Is it OK to do the throttling on the UI side after it catches the events, or should it be in the class library that creates the events? Let's assume you want to re-use the class library. (I'm assuming it makes sense to throttle in the class library down to the max events per second you'd ever want)

Answer 1

I would say do the throttling in the UI. After all in 6 months time there might be a machine that can handle your current event rate.

It could also be that certain controls can handle faster event rates than others, so these should update as often as they can rather than as often as the slowest.

Answer 2

Hi,

did you try to update without throttling? Did you see a real performance problem? Or do you just expect to see one? I actually wouldn't do anything here before I'm sure that I have to.. ;)

From another point of view, how many changes can your users really see/react to? This article suggests that humans perceive everything from about 13 to 15 frames and upwards as seamlessly animated. Perhaps that could be a sensible indication for a limit of the update frequency? HTH.

PS: As far as I know the throttling can be done quite nicely be using the reactive extensions. This question shows a bit about it.