Android [1.6.0]: Strange rendering behaviour on NumericAxis


I have a NumericAxis which is a large negative Double which used to be a timestamp until recent requirements made me change it. Now my rendering has gone from a nice continuous line to a quantized line where most of my points are at the same level. It’s really strange. Here’s a picture:

I have traced this down to the rendering in the chart. I put a long-press action on the chart to extract the points from the datasource and the charted (in a spreadsheet) data is correct. So the DataSource has correct data, and yet Shinobi is rendering it like above.

Anything I can look at to make this work as I would expect? I was previously using a DateTimeAxis, but really need to have it be a NumberAxis instead. Why is it quantizing the numbers like this?

I turned on the point display just so I could understand why most of the lines were going sideways on the chart. See how many points are lining up on these regularly spaced lines? Those lines don’t even line up with any of the major or minor gridlines.

I hope there’s a way out of this one, easily.


So, I’ve managed to make a very simple test program that demostrates this problem. It turns out that I guess Shinobi has internal limits on the number of significant digits of a Double precision value. I’ve made a github repository (minus the shared libraries and jarfiles for Shinobi) that shows this phenomenon. The application tries to render a Sin curve based on a conversion of the current time to a double precision number. As the numbers get larger (> 200 days) the chart starts to render increasingly poorly. I see multiple values of the data source being rendered at the same Y coordinate in the chart, as well as a strange ‘sliding’ of the gridlines behind the chart values.

In, you will see some lines that look like the following.

// Setting this date closer to the actual date fixes a resolution issue
// with the internal chart representation of the data. In this demo, setting the
// value to -200, causes a stair-stepping effect. But -100 does not have this effect.
// The lower this 'delta' becomes, the more closely the chart represents the values.
Calendar c = Calendar.getInstance();
c.add(Calendar.DATE, -200); 

If you change the -200 value to -2 for example, the chart will render properly, and panning the chart will update much more smoothly. Setting this to a value like -1000 has terrible effects.

Why is Shinobi forcing me to reduce the significant digits of my double precision values in this way?


I was able to find a pretty decent workaround with some hints from Patrick about overriding the transformUserValueToChartValue() and transformCharValueToUserValue() on the Axis to reduce the significant digits by subtracting a reference date from all values in the chart, and adding that back in again in the opposite transform. I’ve added a commit to the github repository I mentioned above.

As explained to me, since OpenGL is being used, there is a conversion from Double to Float going on somewhere inside, and we all know that the IEEE Float representation cannot represent every value equally, so the higher the number of significant digits, the more chance of a non-unique representation on my Y axis.

I hope this helps someone else.



Thanks for sharing this Neal! Glad to hear it helped.