Pre loader

DX10 surface not working for certain chart types and chart resizing

Welcome to the SciChart Forums!

  • Please read our Question Asking Guidelines for how to format a good question
  • Some reputation is required to post answers. Get up-voted to avoid the spam filter!
  • We welcome community answers and upvotes. Every Q&A improves SciChart for everyone

WPF Forums | JavaScript Forums | Android Forums | iOS Forums

1
0

Firstly we have an issue at the moment using the high speed renderer. We have a window containing a tab control with several tabs. One of the tabs has several charts and the other tabs contain grid controls with 100’s to 1000’s of rows. The issue seems to be when re-sizing the window with the chart tab visible.
The charts hang on redrawing. When the tabs with grids are selected re-sizing is normal and fast. Only when switching to the tab with charts does it hang.

It also seems that separate charts in different windows also become affected when re-sizing them too. Seems they all share the same renderer instance?

I’ve profiled the re-sizing in visual studio and attached a screenshot of the method calls. Seems a lot of time is taken in RenderSurfaceSizeChanged and it’s children

When I don’t populate the grids, the re-sizing is better but there is still a bit of a hang.
Here is the xaml I’m using for each chart control

   <s:SciChartSurface x:Name="Chart"
                           ChartTitle="{Binding ChartTitle}" 
                           FontSize="14"
                           FontWeight="Bold"
                           RenderPriority="Normal"
                           Background="WhiteSmoke"

                           s:ThemeManager.Theme="ExpressionDark">

            <s:SciChartSurface.RenderableSeries>
                <s:FastColumnRenderableSeries x:Name="ChartDataSeries" 
                                             >
                </s:FastColumnRenderableSeries>
            </s:SciChartSurface.RenderableSeries>
            <s:SciChartSurface.XAxis>
                <s:CategoryDateTimeAxis Style="{StaticResource AxisStyle}" DrawMinorTicks="False" DrawMajorTicks="False" DrawMinorGridLines="False"></s:CategoryDateTimeAxis>
            </s:SciChartSurface.XAxis>
            <s:SciChartSurface.YAxis>
                <s:NumericAxis Style="{StaticResource AxisStyle}" LabelProvider="{StaticResource QuantityLabelProvider}"  DrawMinorGridLines="False" DrawMajorTicks="False" DrawMinorTicks="False"  />
            </s:SciChartSurface.YAxis>
            <s:SciChartSurface.ChartModifier>
                <s:ModifierGroup>
                    <s:RolloverModifier ReceiveHandledEvents="True"/>
                    <s:CursorModifier ReceiveHandledEvents="True" ShowAxisLabels="False" ShowTooltip="False" />
                    <s:RubberBandXyZoomModifier ReceiveHandledEvents="True" IsEnabled="True" ExecuteOn="MouseLeftButton" IsXAxisOnly="True"/>
                    <s:ZoomExtentsModifier ExecuteOn="MouseDoubleClick"/>
                    <s:ZoomPanModifier ReceiveHandledEvents="True" x:Name="ZoomPanModifier" IsEnabled="True" ExecuteOn="MouseMiddleButton"/>
                    <s:MouseWheelZoomModifier ReceiveHandledEvents="True" ActionType="Zoom" XyDirection="XYDirection"></s:MouseWheelZoomModifier>
                    <s:YAxisDragModifier IsEnabled="True" />
                    <s:XAxisDragModifier IsEnabled="True" />
                </s:ModifierGroup>
            </s:SciChartSurface.ChartModifier>
        </s:SciChartSurface>

We tried using the DX10 surface and this fixed the issue above, but it seems it’s not working for at least candlestick charts and column charts – the very charts we need. This can be seen by using the wpf samples.

Update:

After more time profiling the application, I think I’ve found the issue. My app loads in about 1-2gb of data into memory, deserializing into a collection. Normally not a problem but when resizing the chart the app hangs for several seconds. It seems the charts create a WritableBitmap which in turn calls MS.Internal.MemoryPressure.ProcessAdd().
Here it forces a garbage collection, and given I have several gigabytes it takes too long.
This connect bug outlines the issue with a possible workaround https://connect.microsoft.com/VisualStudio/feedback/details/687605/gc-is-forced-when-working-with-small-writeablebitmap

Trouble is I don’t have the chart source to implement this.
I’ve attache a screenshot of the call tree in my profiling, highlighting the MemoryPressure.ProcessAdd() call. Here it take 7 seconds to complete.

Images
  • You must to post comments
0
0

Hi Jakupj,

Perhaps you could contact support [at] scichart.com with a solution to reproduce, or more info about your hardware specification and installed DirectX SDK. Here is a screenshot of me running the Examples Suite ‘Create Multi Pane Stock Charts’ demo, displaying both Candlestick and Column charts in the DirectX renderer in SciChart v3.1. I am also running inside a Parallels Desktop 8 virtual machine (running Win8) on a macbook.

From your description it sounds like there is some underlying usage issue, or Scichart issue in the software renderer, that is improved slightly (but not resolved) in the DirectX renderer. We will need more info from you to reproduce to solve this.

Best regards,
Andrew

Images
  • J Jakupi
    I've tested it on different 4 systems and all are getting the same result. I'll open a tick and send a sample app.
  • Andrew Burnett-Thompson
    Hi Jakupj. Did you send a ticket? We have been working on memory in SciChart v3.1 DirectX surface. We discovered a memory leak in the DirectX implementation which causes you to run out of video memory. With a Graphics card with low video memory the result is a blank surface. We have fixed this in our internal build and deployed to NuGet: v3.1.0.4835. There are other things we are working on such as improving our caching to make it more flexible depending on video memory availability.
  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.

Try SciChart Today

Start a trial and discover why we are the choice
of demanding developers worldwide

Start TrialCase Studies