If you have multiple axes it appears that the order given isn’t honored on the screen.
If signals A, B, C, D are inserted into a list (inserting each item at the zeroth index) the resulting list is D,C,B,A. The order of the list is ignored and order observed is incorrectly: A,B,C,D. The order of the series/y-axes should reflect the order of the list (not the order in which they were inserted).
The following example has been added which shows this. (Clicking “Insert Signal at beginning” multiple times).
Currently we are using a work-around for which any list change, all signals are removed and re-added in the desired order to get the desired result. This is quite slow and causes flickering and flashing of elements on the screen.
Its been 3 weeks since I’ve heard any response..
DateTimes are represented with ticks equal to 100 nanoseconds– But using a DateTimeAxis I cannot plot points down to this level.
It appears that the axis is converting to doubles behind the scenes and thus loses the precision that a DateTime has. When zoomed in the chart pan and zoom has erratic behavior (freezing and not responding in what appears to be a non-systematic way).
I’ve attached a simple solution that reproduces the unexpected behavior.
We are evaluating SciChart for use in our product which includes displaying digital signals. Our goal is to display thick(er) bars when the bit is on and a thin line when it is off. I’ve enjoyed your API so far and have found a simple way of achieving this with the FastBandRenderableSeries paired with the XyyDataSeries.
The issue I’m facing arises when the digital step change isn’t honored at some point during the rendering
(because the issue comes and goes with different states of zooming or panning).
Attached is a screenshot which shows the behavior we are seeing.
We are outputting the data-points as the diagram shows (not inserting extra points to dictate when the edge falls or rises). The following shows the data points we are outputting and the lines we want drawn.
1-------1------ | 0-------0
We could also potentially try outputting extra points to see if that could work around the issue–But as a part of our trial we would like to get a feel for SciChart support responsiveness.
1-------1----*1 | 0-------0
In this second diagram ‘*’ is the artificial point injected to potentially sidestep the issue.
Let me know if there is any additional information can provide.
Update — Added reproduction solution
Is there some kind of bug bounty? 😛 Just kidding.