Performance issues with crowded data

[hodaya273]

In the attached project I present crowded data with 100 points.
I saw that when render mode is Vector, there is a slight difficulty in resize. This difficulty does not exist when I change the mode to Hardware.

The more points I show the more difficult there is to draw in vector mode (at 100,000 points it becomes really bad).

My question: Can I know or calculate when to graph it is difficult to draw to make the mode for Hardware?

[phansen]

The performance limit for a given application will depend on the amount and rate of data sent to the graph and the system it is running on. So there is no pre-determined limit that will make sense for all applications; it will depend heavily on your scenario.

The Vector render mode creates WPF visual objects to represent each plot, so as the number of plots and points increases, you will be limited by the WPF rendering system. The Hardware render mode does not offer the same rich graphics capabilities as WPF, but it does take advantage of graphics hardware acceleration (when available), and its cost is limited to the size of the plot area (without regard to the number of plots or points). The simplest approach would be to stick with the Hardware render mode if you expect to see large amounts of data.

[hodaya273]

The problem is not the large amount of data, but the density of data. As you can see in the project that 100 dense data is difficult to be seen in Vector.

I would like to simulate the graph in the back thread to see if there is any difficulty in drawing before I turn the graph into Vector. But I saw that it is not possible to create a demo graph in a thread that is not UI, and besides, the rendering of the graph does not take the necessary time when it is not displayed on the screen
Is there a function that can be used to sample the painting/rendering time from "behind the scenes" (a function of the graph or of a particular plot)?

[NickelsAndDimes]

Hi hodya273,

What exactly do you mean by the "density" of the data? If you're referring to how close/far away the points are form each other, I didn't see any change in behavior when I altered your code to generate the same number of points over a greater X range. The only way I was able to reliably cause the Vector rendering to take longer was increasing the actual number of data points. This seems to point back to phansen's explanation, Vector rendering is being limited by the WPF rendering system.

[phansen]

---

---

...it is not possible to create a demo graph in a thread that is not UI...

WPF does support running multiple UI threads in a single application. There are some known issues with Hardware rendering on multiple threads that require special initialization to avoid, but since you want to measure Vector that should not be an issue. See the Wpf graph with visual host question for an example.

---

---

...besides, the rendering of the graph does not take the necessary time when it is not displayed on the screen...

In order to test rendering, the graph does need to be loaded (though its visibility can certainly be Hidden). It may also be possible to force this manually using the technique from the Create WPF element offscreen and render to bitmap question, without needing to host a hidden visual in the main window.

---

Is there a function that can be used to sample the painting/rendering time from "behind the scenes" (a function of the graph or of a particular plot)?

There are no methods or events that would allow direct measurement of the render time. It might be possible to achieve this using a custom PlotRenderer to sample render calls. A more general approach would be to do a Dispatcher.BeginInvoke to the background thread, and see whether it is called before a timeout on the main thread has elapsed.

---

One other consideration, based on your example application: chart collections are not thread-safe (they expect all updates to happen on the same thread as the graph they are assigned to). You could assign the same pre-initialized chart collection to both graphs (i.e. it should be safe for the two threads to read from an unmodified collection), or create equivalent chart collections on both threads.

Also, if you assign an empty chart collection to the background thread and then append data, the graph will dispatch (waiting for all appends to complete) before processing any of the data. To measure rendering performance, it would be best to assign the full set of data to the background graph once (assuming the graph is already loaded, it will immediately process and render the assigned data).

[hodaya273]

I changed the project to display the data in HW mode. And I have 2 buttons for checking Render Time in Vector mode.
The first button checks the render by adding a demo graph to Visual Tree and the second button checks the Render by a thread (STA), using Measure and Arrange.
You can see that the check on the thread when the graph is not displayed on the screen does not take the amount of time as the check on the UI when the graph is displayed.

[phansen]

I believe the problem is the background graph is not hosted in any rooted visual tree, so WPF will not render it (even with the manual layout calls). For example, if you put the demo graph in a separate Window, or use the HostVisual method from the earlier link, then the background graph will render normally.