SciChart DPI Issue where DPI != 96

A few of our users have reported issues when using non-default DPI with SciChart. So what it all is about? Lets try to reproduce the issue using the steps below:

1. In Windows, go to the Display settings and change the scaling level.
2. Log out so the changes are applied.
3. Run the SciChart WPF Examples app.

And here is what you will probably see on the screen (200% scaling vs default):

The chart is rendered with blurry, indistinct grid lines, ticks and series.

ActualWidth != PixelWidth when DPI is not 96

If you were to inspect the example with WPF Snoop, it will reveal very interesting results.

The reported ActualWidth, ActualHeight of SciChartSurface differ from the real pixel widths and heights!

This is a known issue in WPF and reported in this StackOverflow post: WPF Giving Incorrect Size Values.

Here is an image to better describe what I'm talking about:

As you can see, snoop is saying that the actualwidth and actualheight of the WindowsFormsHost is 486x336. Any debug information I log says the same thing. However, when I Print Screen and crop to the control in paint, the actual size is 608x423, a sizeable difference.

So what's the Reason for this?

This happens due to the fact that WPF applications are system-DPI aware by default. All sizes in WPF are given not in pixels, but in the device-independent units, which are referred to as DPI (dots per inches).

This is fine in normal WPF applications, however SciChart makes heavy use of the WriteableBitmap and D3DImage type to draw directly to bitmaps or share DirectX content with WPF. Here, we need real pixels. The real problem is that there is no way to get the actual size of a control in pixels. Neither one can obtain DPI values using framework capabilities, and therefore is forced to call native API functions or introduce a dependency on Windows Forms/GDI+ infrastructure (see this article for reference).

SciChart uses bitmaps and textures for drawing, so it heavily relies on low-level manipulations in pixel arrays. Unfortunately, because of the above-mentioned WPF limitations, it is quite hard to make a charting component with fast enough drawing and the capability to adjust to the scaling level of system. It would additionally involve significant amount of computations at every redraw and therefore it would cause a decrease in performance. As charting speed is the main benefit of SciChart, we are hesitant to add a workaround to the codebase.

Resolution with SciChart v4's new Vector Rendering Plugin

As of SciChart v4, we now support a Vector Rendering Plugin, which is DPI Aware. You can test out this plugin in the latest SciChart Examples Suite by going to Settings -> Vector (Highest Quality). On systems with DPI != 96 you will find that this rendering plugin yields a considerable quality improvement on high DPI screens.

As you can see from the above screenshots, with the Vector rendering enabled, the quality is much crisper at high DPI. This is because the Vector rendering plugin uses WPF Elements only for drawing, which are by default DPI aware, and work around the problems inherent in Bitmaps and Textures. 

Enabling the Vector Rendering Engine in your code

To enable the Vector Rendering Plugin in your code, you simply need to set the XamlRenderSurface as active:

<s:SciChartSurface>
   <s:SciChartSurface.RenderSurface>
      <s:XamlRenderSurface/>
   </s:SciChartSurface.RenderSurface>
</s:SciChartSurface>

NOTE: The XamlRenderSurface is available as part of the SciChart WPF 2D Enterprise and SciChart WPF SDK Professional / Enterprise editions.

Further Reading

 To learn more about all renderer types available in SciChart, please see this documentation article.