Dynamic chart

[asynchaizer]

Hi, I have a need for a line graph that can work with dynamic data that comes from a sensor at high speed (more than 50-100 points per second), the sensor can be turned off at any time and the readings obtained can be studied.
I have a number of questions:

1. Can I work with dynamic data? Are there any optimizations for this?
2. Is it possible to set pan restrictions? Here I am more interested in the width limit (Maximum number of displayed values)
3. Can I programmatically move the panoramic view to the end each time new values are added? I understand that there is no desktop solution right now, but I would like to clarify this within the Android.

[gsteckman]

1. Yes it can work with dynamic data. There is an example in the Samples project, have a look at LiveTimeChart.kt. Specific optimizations have not been made for performance. But practically speaking if a person is looking at the data I don't think it would require a 100 Hz refresh rate, a few times per second is likely sufficient.
2. Yes this can be set by adjusting the min/max range of values to be plotted on an axis.
3. Yes, also controlled by the min/max range on the axis. There is a desktop solution but manually zooming/panning with mouse/touch only works on Android for now (Compose limitation - maybe it works on Apple devices but I don't have any to test with so I don't know).

[asynchaizer]

Yes, you're right. Probably "zoomRangeLimit" should be replaced with "zoomInLimit", and also add "zoomOutLimit". Alternatively, for "zoomRangeLimit", replace the parameter type with Range, but in this case there may be a dual understanding - "min is zoomIn or zoomOut?", so I would prefer more explicit names that directly reflect the essence.

[gsteckman]

I think keeping with the data type of the axis and having 2 values is going to be more clear than using a Range. Other name options are minViewExtent/maxViewExtent. I'm not sure if that is more clear than zoomInLimit/zoomOutLimit?

[asynchaizer]

The names "zoomInLimit/zoomOutLimit" are directly related to zoom, they are intuitive and emphasize the scaling process. The names "minViewExtent/maxViewExtent" - I have not seen names in practice that were associated with "viewExtent", but I will assume that this option is as good as "zoomInLimit/zoomOutLimit", but this option focuses on the displayed range of data, and not on the concept of scaling.
Since these names will limit not only the scaling process, but also the setting of the current range (setViewRange), I think the names "minViewExtent/maxViewExtent" would be preferable, since in the future a function may appear that is not related to scaling, but these parameters will affect this function.

[gsteckman]

Hi @asynchaizer, after the gesture improvements you recently made, do you think it would still be helpful to have a minViewExtent/maxViewExtent setting on the linear axis? So zoomRangeLimit would be replaced with minViewExtent, and a new parameter maxViewExtent would be introduced to potentially prevent zooming out all the way to the maximum range of the data.

[asynchaizer]

Hi @gsteckman, I still think it needs to be implemented.
This will be especially useful on large data samples, because I noticed a decrease in rendering performance in such cases, the problem is observed from about 2000 points in the visible range, in the near future I plan to familiarize myself with this problem in more detail.

[gsteckman]

Hi @asynchaizer, I just committed this change. Do you have any use cases to try it out with? I haven't tried doing any scale testing or optimization of the library yet, but that would definitely be interesting to see if you have the time.

[asynchaizer]

Hi, @gsteckman!

I have checked and it works well. There is one problem, for currentRange it is necessary to apply a restriction when initializing AxisModel, since now the restrictions of the viewExtent are applied only when changing the currentRange through the setViewRange method.

There is also a loosely coupled problem in the zoom implementations - this is not critical, but it affects the UX charts. When the zoom is maximum or minimum, when trying to zoom in/out, only the zoom offset starts working, but in fact I expect that there should be no offset, because the offset should occur with zoom in/out.

Here's what I managed to find when reviewing performance, I tested only LinePlot on real data - 3 lines, totaling ~22700 points :

1. The highest load occurs due to the rendering of Symbols, performance drops to <1fps or rendering is completely blocked and the application freezes. It seems inevitable and easier not to use Symbols on big data. The only idea is to provide a more flexible implementation of Symbols, for example, so that it is possible to put dots only in the right places, for example, at peak values or only for maximum/minimum values. I think the performance issue when using Symbols should be documented.
2. I also noticed that Path is used to build lines, as far as I know Path is slower than native calls to Canvas methods, I tried to quickly rewrite it to the native Canvas.drawLine method and got a performance gain of ~10-15 fps. Despite the fact that the lineTo method inside Path works 2 times faster than Canvas.drawLine, drawing Path inside Canvas eventually turns out to be more difficult with an increase in the number of points.
3. It may be worth checking the Canvas.scale and Canvas.translate methods, perhaps they will be more productive.
4. We can potentially get a performance boost if we select only those points that are really needed for rendering each time. Now, every time we draw, the lineTo method is called for all points, but in fact it is enough to draw only those points that are in the visible range.
5. We can increase productivity with several lines in the diagram if we draw them in parallel, for example, now if we draw 3 lines, it means that the cycle will be started 3 times, but in fact it is possible to draw lines in 1 iteration of the cycle. This requires passing all lines to 1 LinePlot function, so it will require some API changes. If we add the previous paragraph to this point, then this way we can reach the limit of efficiency in collecting the necessary points for rendering

[gsteckman]

Good catch on those min/max view extent issues. I checked in code that should fix them.

Path was used in order to support area plots so the same initial path could be used to draw the line and then form one boundary of the fill area. There's also been some interest in being able to draw smoothed curves, and path can draw Bezier curves but as far as I know DrawScope doesn't have a function to do it.

Can you elaborate on what you mean with point 3?

I'm not following you on point 5. Since Compose is single threaded we can't launch separate threads, and I assume the loop overhead is small, which is typically the case, relative to the line calls.

Thanks for looking into this and for the input.

[asynchaizer]

Hi @gsteckman !

2 - We can make the Path a separate implementation, especially for Bezier curves. We can also implement the Bezier algorithm ourselves using DrawScope, this is definitely a more difficult way (or maybe more interesting?)

3 - I mean, perhaps the pan and zoom functions can be performed using the native DrawScope.scale and DrawScope.translate methods. But so far, these are just abstract assumptions.

5 - Yes, that's right, rendering takes place in one thread. But not everything is rendering, some of the calculations can be done in the background, for example, you can see an example of such a function here.
Now such logic is difficult to implement, since it is almost impossible and very expensive to synchronize the construction of two or more lines on the chart at the same time, because now each line is processed independently of the other.

Perhaps this is one of the ways to reduce or eliminate the impact of the complexity of the amount of data on the UI stream.
On the other hand, if we put a number of calculations in the background, we will get a delay when using real-time diagrams, which is not always acceptable 🤔

[asynchaizer]

In 5, I rather meant to start by trying to draw all the lines within 1 LinePlot, so we will have 1 Canvas for the lines of the diagram and a minimum number of accesses to data samples by drawing all the lines in 1 iteration of the cycle. I'm not ready to say how much more productive it is yet, but it should definitely save rendering time.