I am currently writing a kiosk style app in UWP (windows IoT Core), for use on embedded devices (e.g. pi3, etc.).
The device has several sensors, which are being output in real time into various graphs/charts in a single screen in the app, but I'm running into performance problems. The sensors are being read in separate threads (using Task.Run() => {}), but after analysis, this doesn't seem to cost that much cpu time at all. It seems that updating the graphs take too much time and this isnt being distributed over the cores, since there is only a single UI thread. CPU usage doesnt get past 25%, the UI responsiveness just gets slow.
I tried several optimizations (e.g. reducing the amount of data points, etc.), which helps, but its not enough. Maybe there are faster chart components out there (currently using Telerik uwp component), but I was looking for another approach.
So summary of my question: Is there any way to have the charts each render in separate UI threads (and thus be distributed over the other cores somewhat)?
[UPDATE some time later] Seems like the new win IoT release is a bit faster, as well as the newer chart component.
Can't speak strictly for UWP but from my experience of WPF having multiple UI threads is a hassle which you should avoid if at all possible (not to speak of the limitations they introduce).
When dealing with your sensor data what kind of polling rate are you looking at? Many sensors have a data rate which far outstrips what is useful to display to the user, would it be possible to have your worker thread compute an averaged value for a larger time frame and populate your graph with that? I doubt your users will see much of a benefit from updating them more than 20 times a second.