SciChart® the market leader in Fast WPF Charts, WPF 3D Charts, and now iOS Charting & Android Chart Components

0
0

Hi,

It looks like something is wrong with the SciChart trend when using FastLineRenderableSeries (don’t know if similar behaviour occurs on different series types). In case of having DPI set to 150% trend is shivering. It looks like he is trying to update constantly. Sometimes is required to change the window size to see the problem however in most cases it is visible all the time. Attached code was tested on Windows 7 with DPI 150%.

I will appreciate any help

<Window x:Class="WpfApplication1.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:sciChart="http://schemas.abtsoftware.co.uk/scichart"
    xmlns:local="clr-namespace:WpfApplication1"
    Title="MainWindow" Height="350" Width="525">
<Grid>
    <sciChart:SciChartSurface x:Name="sciChart" Margin="0,0,20,30" BorderThickness="0"  sciChart:ThemeManager.Theme="BrightSpark">
        <sciChart:SciChartSurface.XAxis>
            <sciChart:DateTimeAxis TickTextBrush="Black"/>
        </sciChart:SciChartSurface.XAxis>
        <sciChart:SciChartSurface.YAxis>
            <sciChart:NumericAxis TickTextBrush="Black" BorderBrush="Black" AxisAlignment="Left" Id="Common" TextFormatting="#.0"/>
        </sciChart:SciChartSurface.YAxis>
    </sciChart:SciChartSurface>
</Grid>

public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();

        XyDataSeries<DateTime, double> dataSeries = new XyDataSeries<DateTime, double>() { SeriesName = "test1" };

        for (int i = 0; i < 10000; i++)
        {
            dataSeries.Append(DateTime.Now, new Random().Next(-1000, 1000));
        }

        sciChart.RenderableSeries.Add(new FastLineRenderableSeries() { YAxisId = "Common", SeriesColor = Colors.Blue, DataSeries = dataSeries });
    }
}
  • You must to post comments
1
0

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 type to draw directly to bitmaps. 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 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.

At this time, SciChart only supports DPI of 96.

At the moment, we have decided to postpone development of DPI-awareness in SciChart for performance reasons. Nevertheless, the issue is logged in our bug tracker. If enough people request (be advised, it will introduce slower performance for drawing) then we will prioritize this issue and develop DPI-awareness in SciChart.

Our recommendation: For now, you should use the default DPI settings (96 DPI) with SciChart in order to get high-quality, crisp chart output.

Best Regards,
Nazar R.

  • You must to post comments
1
0

Hi

Here is a full link to our support site (which is back up now), which explains why SciChart is not DPI aware at this time. We may review this in the future.

Best regards,
Andrew

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.