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


Is there an example of building a custom axis using a long or ulong?

So far I’ve tried implementing AxisBase and created necessary types for the given interfaces (IRange, IDeltaCalculator, IAxisDelta). But after implementing the minimum set of pieces, the chart comes up blank.

Also strangely the only two functions that get called on the AxisBase implementation are

IsOfValidType() — This gets called with a DoubleRange rather than my ULongRange.. Somehow a DoubleRange is being introduced, but I can’t see how.

Is there any good documentation/design info out there about how to do this?

I have attached the solution I’ve been working with.

  • Riley Huddleston
    The driving force for wanting to create a ulong axis is because we need a DateTime axis that can zoom into ~1 microsecond. The DateTimeAxis doesn’t provide this much zoom capability (I think this is because of the use of double value types).
  • Riley Huddleston
    We are about to be a paying customer, but this issue outlined here is a high risk task for our product. The last post related to this question hasn’t been responded to in 6 days — Thus this question.Is there a way to setup a meeting/live chat deal (or is that only for sales)?
  • Paul Frivold
    I’ve been working with ~1 microsecond precision data with sciChart. Ended up using a regular numeric axis with microsecond timestamps, and writing a LabelProvider to convert them to ms / seconds / minutes. Wasn’t too difficult, and I’m very much a novice programmer. That said, there might be a better way to do this. Hopefully you get a reply from the SciChart folks soon!
  • Andrew
    Hey Paul, we were discussing with the team, and also Riley’s company via support ticket yesterday, pretty much suggested the same thing. It’s not pretty but it will work. The problem of precision runs through more than just the axis, because of .NET lack of long-double or double-double data-types. Maximum bits available for computation is 64! :/
  • You must to post comments
Great Answer

For a bit of context here.

SciChart internally uses Doubles for most computations, for example, converting data-coordinates to pixels, issuing of drawing commands etc… We have to use the highest common denominator for precision throughout (which is Double-64bit) despite data storage being generic. Making generic axis is out of the question since Xaml hates generics on types. Making a custom axis is also out of the question since more parts in SciChart rely on DateTime-Double conversion, such as Coordinate Calculation, Drawing Commands and more.

When converting from DateTime -> Double it is possible to lose some precision. This is because DateTime has 64-bit precision for all values allowing down to 100ns increment, whereas Double only has 52-bits mantissa and 11 bits exponent, plus 1 bit sign. Going from 64-bit to 52 means that if you use DateTime in your axis and require 100ns on the time scale, then you will start to experience this precision loss. Sadly there is no Long-Double type in .NET (like C++) and decimal, while 128 bit, does not have the dynamic range of double, so it is unusable.

As a result, we are at an impasse. Unable to solve this problem.

We do have a good workaround however. It is to use NumericAxis and LabelProvider (thanks to Paul Frivold for confirming its use in the field)!

For example, if your data ranges from 1st Jan 2016 – 1st Jan 2017 and you want a scale of 100ns, you can represent the data like this:


Now use LabelProvider to format the labels as a Start Date plus 100*X nanoseconds, where X is the X-value.

The LabelProvider API feeds into both axis labels and tooltips so your users will be unaware you are using whole numbers under the hood.

Let me know if this helps,
Best regards,

  • Riley Huddleston
    Yes, agreed– This is what we have done in the past with our previous third-party chart. It can get nasty quick when you need to do this (i.e. when you have a time segment the passes the precision of the type on the right hand side). Having the offset from the left side of the current zoom wouldn’t probably work as you’d have to update all data point timestamps for every zoom and pan type operation.Thus we will have to fallback to some date that is near the start of the data’s time and will give up long, high sample rate reports.What we were hoping for was a way to calculate arbitrary data for points, then supply some kind of value to pixel converter. But– I understand that this was not the architecture (and would have made for a more complicated architecture).I appreciate your responses. Also, SciChart’s chart is a pleasure to work with, so hats off to your designers!
  • Andrew
    Potentially it would be possible to change the architecture, but it would require a deep change to the source code. I did find this library a long time ago that can handle 128-bit doubles on .NET (for the same problem actually). Including something like the above would work, but it would impact performance quite negatively as well.
  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.