Pre loader

"upside down" log chart

Welcome to the SciChart Forums!

  • Please read our Question Asking Guidelines for how to format a good question
  • Some reputation is required to post answers. Get up-voted to avoid the spam filter!
  • We welcome community answers and upvotes. Every Q&A improves SciChart for everyone

WPF Forums | JavaScript Forums | Android Forums | iOS Forums

0
0

I’ve created a chart with a FastColumnRenderableSeries and a logarithmic Y-axis with a VisibleRange of min=1e-13, max=1e-7. However the resulting chart appears “upside down”, which I understand is a consequence of plotting values <1. Is there any way to “correct” this?
Plotting my data in Excel initially exhibits the same “upside down” behaviour, but can be corrected by setting the “Horizontal access crosses” axis option to 1e-13, so is there an equivalent setting in SciChart? I thought it might have been the ZeroLineY property, but playing around with this had no effect.

As a cheat/workaround I’ve switched to a FastLineRenderableSeries, as you don’t see the upside down effect, but the preference is for a column chart. (I’m rewriting a very old app that uses Dundas, and this does somehow render the data the “right way up”, so I know customers are going to want a like-for-like bar chart).

Version
6.6
  • You must to post comments
0
0

This seems to have been down to timing of bindings. Although the VM assigns YAxisRange (bound to the Y-axis VisibleRange property), I found I had to assign a dummy range to YAxisRange in the VM constructor. This now appears to have fixed the problem.

  • You must to post comments
0
0

Hi Andrew,

Thanks for your inquiry.
We would appreciate if you provide us with more details regarding the issue you are experiencing, such as some pictures or mockups showing the current chart appearance compared to the desired state.

Please also share the steps to reproduce the described behavior in one of our examples from the WPF Examples suite, e.g. “Logarithmic Axis” example:
WPF Chart Logarithmic Axis Example – SciChart

I have also noticed you use an outdated SciChart version.
We recommend using the latest one, which is SciChart v8.6 currently, as it always includes all the latest fixes and updates.

Kind regards,
Lex,
SciChart technical support engineer

  • You must to post comments
0
0

Hi, as explained in my question it’s a FastColumnRenderableSeries with logarithmic Y axis, and the values being plotted are small (1e-13 to 1e-7). The issue occurs because such small values convert to -ve numbers on a log axis, resulting in that strange upside down effect. It’s a “known” problem in that all charts do it, even in Excel.
I’ve attached an example screenshot showing the problem, where you can see the columns coming down from the top of the chart creating that “inverted” effect. (Ignore the pale blue area – that’s a box annotation).

I actually found a fix last night. As hinted at in my question, the answer was to use the ZeroLineY= attribute on the series, and set this to Y-axis min (1e-13). The crucial part is that I have to use a FastMountainRenderableSeries. ZeroLineY has no effect when using a column series, so I suspect that’s a bug (at least in my version of SciChart).
The second screenshot shows the chart rendered correctly with a mountain series.

Incidentally I’ve noticed a few strange issues over the years with FastColumnRenderableSeries. My chart lets users switch between a numeric and log Y-axis using your SwitchAxisTypeBehaviour (https://www.scichart.com/example/wpf-chart/wpf-chart-example-switch-axis-type-at-runtime/). When using a FastColumnRenderableSeries, the series often won’t render at all, but it all works faultlessly when using a mountain series instead.

Images
  • You must to post comments
0
0

This is a really strange one. The mountain series worked a couple of times then running the app later in the day it was back to being “inverted” (and no code changes in between). I’ve since noticed that the column series does actually work, but again only very occasionally. It’s as though the vast majority of the time the chart is ignoring the ZeroLineY setting. Here’s the xaml – as you can see it’s nothing out of the ordinary:

<s:SciChartSurface RenderOptions.EdgeMode="Aliased"
               DebugWhyDoesntSciChartRender="False"
               Margin="8">
<s:SciChartSurface.RenderableSeries>
    <s:FastMountainRenderableSeries DataSeries="{Binding ChartSeries}"
                                  ZeroLineY="1e-13"
                                  Fill="{Binding CollectorColour, Converter={StaticResource colorToBrushConv}}"
                                  Stroke="{Binding CollectorColour}"
                                  StrokeThickness="1"
                                  AntiAliasing="False" />
</s:SciChartSurface.RenderableSeries>
<s:SciChartSurface.XAxis>
    <s:NumericAxis Style="{StaticResource AxisStyle}"
                   s:RolloverModifier.AxisLabelTemplate="{StaticResource RolloverAxisLabelTemplate}"
                   AutoRange="Always"
                   DrawMajorGridLines="True"
                   MaxAutoTicks="8"
                   DrawLabels="True" />
</s:SciChartSurface.XAxis>
<s:SciChartSurface.YAxis>
    <s:LogarithmicNumericAxis x:Name="yAxisLog"
                              Style="{StaticResource AxisStyle}"
                              AutoRange="Never"
                              VisibleRange="{Binding YAxisRange, Mode=TwoWay}"
                              TextFormatting="0.0###e+00"
                              DrawMajorGridLines="True"
                              MaxAutoTicks="8"
                              DrawLabels="True"
                              AxisAlignment="Left" />
</s:SciChartSurface.YAxis>
<s:SciChartSurface.ChartModifier>
    <s:ModifierGroup>
        <s:RolloverModifier DrawVerticalLine="True"
                            ShowAxisLabels="True"
                            ShowTooltipOn="Always"
                            UseInterpolation="False"
                            SourceMode="AllVisibleSeries" />
    </s:ModifierGroup>
</s:SciChartSurface.ChartModifier>

I don’t suppose there’s any way to confirm whether this was a bug in v6.6 that has since been fixed?

  • You must to post comments
Showing 4 results
Your Answer

Please first to submit.