SciChart® the market leader in Fast WPF Charts, WPF 3D Charts, and now iOS Charting & Android Chart Components
We also have a tag=SciChart on Stackoverflow.com where you can earn rep for your questions!
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.
When rendering a FastLineRenderableSeries, there are line segments missing both before and after a double.NaN Y value. This makes sense for a regular line series, but for a step line series (where IsDigitalLine=True), why isn’t the line segment preceding the NaN being drawn? When plotting (for example) financial prices over time, the missing line before the NaN gives the impression that a price didn’t exist for that period, which is incorrect.
I’m looking at the IterateLines method in FastLinesHelper. Even though the method has an isDigitalLine parameter, it isn’t checked during the handling of a NaN value. Is this an oversight?
Thanks very much,