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

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 regarding how many UI changes update events one should allow through per second? (For example, 10 per seconds say) - in开发者_Go百科 my case they'll be driving a change to values in a bar graph (that is, 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.)

---

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.

---

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.