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

0
0

I have a ViewPager which switches between Fragments that have a SciChartSurface in their layout. I have two problems with this.

  1. When swiping the ViewPager the SciChartSurface shows a black bar on its side (see attached image).

  2. When swiping I cannot achieve 60 fps on my device. Upon inspecting systrace I see scheduling delay for each frame. Upon inspecting Android profiler’s flame chart I see that SurfaceView calls android.os.BinderProxy.transact() which takes most of the time. If I change the layout of the Fragments used in ViewPager to a normal View, then android.os.MessageQueue.nativePollOnce() takes about 80% of the time, which means most of the time the CPU is idling because drawing takes up so little time.

My question is how can I solve both problems. Have I configured the SciChartSurface wrongly to get the black bars. Can I do anything to speed up changing tabs in ViewPager with SciChartSurfaces in the Fragments?


Edit 14. 1. 2019

I have attached a sample project to reproduce the problem.

Version
2.2.1.2391
Images
  • You must to post comments
0
0

Hi Miha,

Can you try to switch to alternative implementation of IRenderSurface which is used to render chart? I believe this issue could be caused by our default RenderSurface implementation. It is based on GlSurfaceView and there is some delay caused by OpenGL initialization when you attach it to View hierarchy so there could be some delay when switching between Fragments. Please try to switch to Canvas based RenderSurface ( it’s a bit slower than OpenGL based RenderSurface but in most cases drawing performance should be OK ):

surface.setRenderSurface(new RenderSurface(getActivity()));

Hope this will help you! If it doesn’t help then please can you attach a project which reproduces this issue so I can take a look on it?

Best regards,
Yura

  • MIha Rozina
    I have tried the Canvas based RenderSurface which did solve the problem of the black bar, but overall performance greatly degraded (when swiping one frame needed 80 ms to render, which is well above 16.7 ms needed for 60 fps). I have also attached a sample project to reproduce my problems. Flame chart was recorded by holding the touchscreen and moving my finger left – right between two pages while not letting it settle on either page. I am looking forward to your feedback in regards to the sample project.
  • Yura Khariton
    I took a look on your example and I didn’t notice anything wrong with FPS. May I ask what device did you use for testing? Regarding Canvas based RenderSurface – well it’s expected that you get drop of FPS because in general Canvas rendering is much slower than rendering which uses OpenGL, but in this case it should with less delay because there is no need to init OpenGL context and allocate resources which are required for rendering of charting with OpenGL. I’m not sure that there is something that we can do on our side because we can’t speed up initialization of OpenGL surface. In this case I would suggest to consider some other ways to scroll between charts which will allow to avoid recreation of SciChartSurface and it’s parts when you switch Fragments.
  • MIha Rozina
    Sorry for the late reply. I am developing an embedded system with which is rather weak compared to current flag ship phones. I have seen in your example app that you have a similar case in “Dashboard style charts” example. Based on that I increased the number of pages hold in memory so the charts are not destroyed on page swipes. Luckily there is enough memory for that :). However I would love a fix for the first problem of the black bars when scrolling. The charts in your example app don’t have a problem, because they have a black background. The black bars are only visible when using a white theme. Are you sure that is not a bug? I don’t see why when translating the SciChartSurface couldn’t keep it’s whole OpenGL surface the same color? If it can draw black, it could draw white as well?
  • Yura Khariton
    Well if it’s a bug then it’s not a bug in our code – we’re using GlSurfaceView provided by Android as base for our RenderSurface implementation and it draws uninitialized texture which has black color until all OpenGL stuff is fully initialized. Also that’s why we can’t draw other color – there is no initialized OpenGL context which could be used for drawing. That’s why we provide several alternative implementations of RenderSurface so you have options to choose from.
  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.