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

Closed
0
0

Hi,

Our current chart setup is as follows: 2 charts, each with 2 line series (~23k data points per line series – datetime [x-axis], double[y-axis]), data is added to the line series in real-time and all data is retained (never deleted). Both charts share a motion events group (pinchzoom, rollover, xaxisdrag, zoomextents).

If you zoom in to the furthest zoom possible, the chart/app starts to act extremely sluggish, then crashes eventually. – see attached txt file for logs.

Questions:

  1. Is there a method to tackle this from a performance perspective and still enable zooming to the utmost limit?
  2. If 1.) is not possible, is it possible to enact a zoom limit on the charts?

Other solution suggestions are welcome.

Version
4.3.0.4686
  • You must to post comments
0
0

Hi Eyram,

That’s very strange. We have an example in our demo application which renders 3 lines series with few millions of points without any problems. Can you try to run it on same device that you’re using for testing?

Have you tried to memory profile your application? Based on your description it looks like that it could be caused by memory leak somewhere, but I can’t be sure without seeing the code. Can you provide a project that reproduces this issue so I can debug it?

Best regards,
Yura

  • Eyram Dornor
    Hi Yura, With the memory profile, there’s a huge uptick in memory usage by native resources right before the app crashes – when zoomed in to the utmost zoom level. A look at the head dump shows a large shallow size of float array. I have the heap dump and native alloc recording for the actual app – don’t know how helpful this would be to you? – let me knw. The sample project I’ve created is not able to replicate the issue. I’m still debugging the original app.
  • Eyram Dornor
    Hi Yura, I was to replicate the issue. Find the project attached to the original post – sciListApp – and video (if I’m able to upload) showing the lagging state prior to crashing. There’s another issue I going to be creating a post for – regarding a visual spline issue – This can be seem in the project as well – I’m wondering if this is the cause on some level, because in switch to FastlineRenderable in the original app, I no longer see the lagging plus crashing. To replicate the issue – scroll to the end (right-hand-side) of the first blob data points – and start zooming in. You’ll notice the spline visual issues – when you zoom in far enough the visual issues vanish, you’ve gone too far, zoom out a bit – scroll to the right with the spline visual issues visible, and you should start noticing some lagging. If you play around enough in that state, the app will crash.
  • Eyram Dornor
    Based on solution identified for – https://www.scichart.com/questions/android/spline-visual-issue – testing to see if issue still exists.
  • Eyram Dornor
    Unable to reproduce – closing.
  • You must to post comments
Showing 1 result