SciChart® the market leader in Fast WPF Charts, WPF 3D Charts, iOS Chart, Android Chart and JavaScript Chart Components
SciChart v1.2.1 was released today! With this release hot off the press, we’re already hard at work at the next set of features and fixes for SciChart v1.3. If you haven’t seen it already, check out our delivery for SciChart v1.2.1 and our new examples application (Requires Silverlight 5). Full details of new features can be found in the release notes of the Trial Download, as well as tutorials / example source to get started using SciChart.
Promises are like crying babies in a theater, they should be carried out at once. ~
Norman Vincen
Firstly a massive thanks to the users, potential customers and just interested developers who gave us valuable feedback for SciChart. You have been patient with us and in return, we will try our best to meet your requirements in a timely manner.
All user requests have been noted and prioritized. The following is a priority-ordered list of features/fixes for SciChart v1.3, with a provisional delivery date of 6th June 2012:
Note: Strikethrough represents items completed in our internal build.
We’d appreciate it if you’d take the time to review this list and comment on this post, or contact us if there’s anything else you’d like to see in there!
– SciChart HQ
15 Comments
Hi,
I hope that another scrolling type can be implemented in the next version (especially for realtime graphs):
Our tests are 20, 30 or even 40 minutes.
There will be a lot of data and if you want to have the last 5 minutes of data on screen, an autoscroll of the Xaxis is great, but not datapoint by datapoint.
With 9 charts or with higher datastreams it will give you a ‘flickering’ screen.
We prefer that if the chart is full, move half or x% to the left and start drawing again.
This way you will only have one complete refresh every minute or several minutes, not every second or even more than that.
Thanks,
Egbert
It’s a great feature idea, thanks! I think the left-shift would involve creating a FIFO buffer of Size + 50% and then when it reaches capacity (Size), flushing half of the buffer. This sort of effect could create great ECG / oscilloscope style charts and hopefully a little easier on the eye!
A common expected behaviour for trend charts is to decouple the refresh rate from both the incoming data rate and from the screen refresh rate.
I would like to see a smoothly moving trend graph that adds data to the right of the trace and drops data off the left as it moves off-screen. The user should be able to choose at run-time how frequently the chart is actually updated.
For example, the data is being displayed in 3 traces, where each trace is being updated at approximately 10Hz. Data arrive one point at a time, slightly offset in time, so the effective data rate is 30Hz. The Silverlight runtime has been set to a 60Hz screen refresh rate (it’s user-adjustable at runtime). Currently in SciChart, the effective refresh rate for the chart will be the smaller of the data rate and the Silverlight refresh rate.
I would like to see an option on all SciChart charts to limit the refresh rate. Many of our target users would like to limit the refresh rate to 1Hz or less. That would mean that the internal data buffers for the chart would be allowed to fill with data (at 30Hz in my example), but that new data would not immediately flag a redraw. The chart would only redraw based on an independent, user-adjustable timer, yet all of the data that arrived since the last refresh would be displayed without loss.
Good idea – This should be achievable due to how SciChart already decouples data from rendering (see “The rendering pipeline” in this article https://www.scichart.com/creating-a-real-time-chart/). Currently the renderer draws as fast as the UI thread is able to (with data handled separately), however limiting the update rate to 1, 10, 30 or 60Hz could be achieved by a flag. As a workaround for you you may be able to call var disposable = sciChartSurface.SuspendUpdates() to freeze drawing and disposable.Dispose() to unfreeze drawing at a specific time, which issues a single draw call.
1)InactiveGraphOpacity
“Gets or sets value specifying opacity of graphs other than the one over whichs legend entry the mouse is located. All other graphs fade to this value when user hovers over legend item”
2)Text with last point value on the right YAxis
Regarding 1) Our internal build now has correct support for IsVisible and Opacity on RenderableSeries.
Need to Update() not only ohlc but lines as well
This has been implemented and in a patch – v1.2.1.678 – which is available from our trial download link now.
Please make the “step line renderable series” an option on the other line rederable series rather than a separate class. I would like to be able to switch the rendering of a line between these two modes at run time, and swapping the line series implementation would be substantially more difficult than setting a true/false flag.
We have implemented step line with the property IsDigitalLine on FastLineRenderableSeries. This will be included in the next release.
Good but I can use it I’m missing:
– Click on a point / column
– CategoryAxis (string)
– axis title
– Change point appearance (color) in the same series
I need notification when range is changed. For example:
ChartSurface.XAxis.OnVisibleRangeChanged or ChartSurface.XAxis.OnRangeChanged
ChartSurface.YAxis.OnVisibleRangeChanged or ChartSurface.YAxis.OnRangeChanged
Good suggestions and easy to implement. Would you mind telling us your use-case that requires this?
When the user change the range, then I need to calculate the area of the visible range.
You may be able to do this already. Please see this tutorial: https://www.scichart.com/extending-scichart-with-text-annotations-and-screenshots/
In particular the file AnnotationsModifier.cs, which handles the Render event (fired immediately before end of redraw). At that point you can query the XAxis, YAxis VisibleRange for any changes. Please feel free to contact us if you require further support.