Based on [this article](https://oxyplot.codeplex.com/discussions/281036) I'm using PlotModel.RefreshPlot(true) frequently to load live data, approximately 20 times per second or so, but the performance is not good. It is sluggish and lags behind.
I have 8 line series with 1000 samples/sec each, but reducing the data frequency does not seem to help much, so this does not seem directly related to drawing performance.
There are a few issues:
* RefreshPlot(true) seems to queue on the GUI thread, probably with BeginInvoke, so that if it runs sluggishly it will also start lagging behind with several seconds in a short time.
* RefreshPlot generally feels very slow for a live data scenario
* The GUI thread is locked for big chunks of the time, so even moving the parent window is very sluggish
I am on a powerful PC with pretty recent CPU and GPU, so that should not be the problem. Running Windows 8, but same is seen on Win7.
I have not yet dug into the source code of Oxyplot, but are there any tips on how to improve live data rendering?
Comments: @tibel: Should I test with your fork or with just the pull request changes? Regarding the oscilloscope example you are right, but I never expected 5 billion fps so to speak. In my repro sample I am only pushing new data to Oxyplot 20 times per second with a timer, or 20 fps. Even so, with relatively little data I am getting 40 fps measured by Performance Profiling Tools for WPF. I believe I would get 60 fps if no work was done on the GUI thread. The large sample rate of the data channels is merely to stress the rendering engine. More samples equals more stuff to render, which reduces the number of frames per second WPF is able to do. As you say, you usually don't get past 60 fps on a normal PC monitor, however it's not quite that simple. If you continuously move your mouse over the window the measured fps will go through the roof, so I'm not sure how reliable this measurement is in terms of measuring oxyplot performance. Maybe there are other metrics or tools more useful for this scenario? In the end, what matters is how smooth the live data updates appear to the user and how much it affects other GUI updates, such as moving the window or animating something else. To my understanding this comes down to how how long Oxyplot is occupying the GUI thread for every data update as well as per CompositionTarget.Rendering event. I have not yet dug into the Oxyplot code, but out of curiosity what drawing API is being used? We did some vector graphics in our software with seemingly good performance, using low level [DrawingVisual objects](http://msdn.microsoft.com/en-us/library/bb613591%28v=vs.110%29.aspx), but even this can be bested on performance using even lower level APIs. Some relevant discussions: http://stackoverflow.com/a/10572086/134761 http://stackoverflow.com/a/8714107/134761
I have 8 line series with 1000 samples/sec each, but reducing the data frequency does not seem to help much, so this does not seem directly related to drawing performance.
There are a few issues:
* RefreshPlot(true) seems to queue on the GUI thread, probably with BeginInvoke, so that if it runs sluggishly it will also start lagging behind with several seconds in a short time.
* RefreshPlot generally feels very slow for a live data scenario
* The GUI thread is locked for big chunks of the time, so even moving the parent window is very sluggish
I am on a powerful PC with pretty recent CPU and GPU, so that should not be the problem. Running Windows 8, but same is seen on Win7.
I have not yet dug into the source code of Oxyplot, but are there any tips on how to improve live data rendering?
Comments: @tibel: Should I test with your fork or with just the pull request changes? Regarding the oscilloscope example you are right, but I never expected 5 billion fps so to speak. In my repro sample I am only pushing new data to Oxyplot 20 times per second with a timer, or 20 fps. Even so, with relatively little data I am getting 40 fps measured by Performance Profiling Tools for WPF. I believe I would get 60 fps if no work was done on the GUI thread. The large sample rate of the data channels is merely to stress the rendering engine. More samples equals more stuff to render, which reduces the number of frames per second WPF is able to do. As you say, you usually don't get past 60 fps on a normal PC monitor, however it's not quite that simple. If you continuously move your mouse over the window the measured fps will go through the roof, so I'm not sure how reliable this measurement is in terms of measuring oxyplot performance. Maybe there are other metrics or tools more useful for this scenario? In the end, what matters is how smooth the live data updates appear to the user and how much it affects other GUI updates, such as moving the window or animating something else. To my understanding this comes down to how how long Oxyplot is occupying the GUI thread for every data update as well as per CompositionTarget.Rendering event. I have not yet dug into the Oxyplot code, but out of curiosity what drawing API is being used? We did some vector graphics in our software with seemingly good performance, using low level [DrawingVisual objects](http://msdn.microsoft.com/en-us/library/bb613591%28v=vs.110%29.aspx), but even this can be bested on performance using even lower level APIs. Some relevant discussions: http://stackoverflow.com/a/10572086/134761 http://stackoverflow.com/a/8714107/134761