Charting: Logarithmic Axis and 3D Charts

Jul 3, 2009 at 11:24 AM
Edited Jul 7, 2009 at 11:46 AM


I just evaluate the charting capabilites of the new toolkit release and I think its great!

But it would be nice to display the linear axis as logarithmic and it would be nice too, to display the charts as 3D charts.

Are there any Option to do this?

If no is it proposed for the next release?




Jul 7, 2009 at 7:07 AM


Yes, LogarithmicAxis is planned for a future release - as is the ability for people to easily write their own Axes to support *whatever* modes they need!

Thanks for your patience!

Jul 7, 2009 at 11:18 AM
Edited Jul 7, 2009 at 11:21 AM

Customizable axes sounds nice. From a previous job, I know first hand that a logarithmic axis can be pretty darn hard to do right. The users expect all sorts of things. E.g. the "1..10..100" labels should always be visible. Then they feed the chart with a dataset that varies between 1.10 and 5.50 and still expect the axis labels to make some sort of sense. It was... Interesting.

What sort of performance are you guys targetting? In the application I worked on, our users typically displayed hundreds of various charts, each updated frequently. (feeding data from Nasdaq/NYSE and other stock exchanges)

Jul 14, 2009 at 2:45 PM


thanks for your response!

I thought you would say that :-)

And what about 3D charts, is it planned too?



Jul 14, 2009 at 9:27 PM


We want our performance to be enough that most scenarios "just work". So if you have realistic scenarios that don't, then please let us know about them and we'll take that into account. :)



3D is planned, but at a lower priority than rounding out our core 2D offering with some of the basics that aren't there yet (like logarithmic, etc.).

Jul 15, 2009 at 10:40 AM
Edited Jul 15, 2009 at 10:40 AM

Well... One scenario: Chart the MSFT stock ticker in real time. Then try with a couple of hundred other stock tickers simultanuously. (keep in mind that you do not need a fancy-looking graph for such usage -- just plain linecharts will suffice)

Jul 16, 2009 at 10:16 PM


It's a fair point. I can imagine there are ways to do that which would have poor performance. However, I also think there may be ways that work with what we've got today. And if there aren't, there will always be scenarios that are out of reach. That's not to say we don't want to reach them now or in the future - just that the primary objective is to address the 80% scenario. And I don't *think* (though maybe I'm wrong!) the scenario you propose is super-common.

Please know that I'm not dismissing the scenario at all - I'm just trying to balance it against other work that might be of greater communal benefit. Hope this seems reasonable!

Jul 17, 2009 at 8:50 AM

I do not know how common it is, but keep in mind all those instrumentation graphs. Everything from Windows' own performance monitor, someone charting voltage drops in hundred different batteries to a tick-by-tick chart of MSFT.

"Realtime charting" is often mentioned when a third-party vendor tries to push their charting component.

Mind you, I haven't tried your charting component, but it will be the first I will try when I need a chart the next time. For my current employer, it is doubtful they will find any use for realtime performance, but I'm sure others do.

Jul 17, 2009 at 4:26 PM

I agree with you both; we're in the genetic sequencing arena, and we definitely have the need for realtime charting.  We're building WPF and Silverlight based applications and we're finding some not-too-pretty performance limitations (not just from the Microsoft toolkit charts) as the number of points or number of series exceeds a certain threshold.  For example, I tried loading 2 line series, each with 10000 data points; it took 21 seconds on a beefy system to load and render the chart.  I think the current release is fantastic for 80% of our cases, but for the other 20%, where virtualization is required and other performance numbers (speed and memory) are gating factors, we need to look elsewhere, or play tricks with the current charts.  For instance, one road I'm on at the moment, will have the data model have 2 components: an observable collection A that's bound to the chart series, but which does not have the entire set of data points, and another collection B which contains all the data points I wish to plot; as such, when I want the chart to plot data between x and x+n, I load that portion from B into A.  For scrolling, I end up dropping some data from A on one side and adding more to the other side; etc.. My poor man's virtualization.

And finally, could we please have zooming, zooming, and umm, built-in zooming? ;)  While you're at it, if zooming can be allowed independently in the x and y directions, that would be wonderful.

Thanks so much, and keep up the good work.

Jul 18, 2009 at 12:31 AM

Thanks for the feedback, everyone!

One quick tip for improving perf of many-point LineSeries is to get rid of the data points entirely. You can do this by providing either a null Style to LineSeries.DataPointStyle or else a LineDataPoint Style with a null or empty Template (these are all conceptually the same; they may not all run, but at least one of them does). This gets rid of a lot of UI overhead and speeds things up noticably. Maybe not enough for 10000 points, but it should help! :)

Jul 18, 2009 at 10:39 PM



For the ones who are looking for great performance and different axes support (including log axes), please have a look to this project also hosted on codeplex:


I am working with tick data(several refresh per second) from different stock exchanges and it works great!!


Do the coordinators have any comment to make between the two projects?




Jul 19, 2009 at 1:12 AM

Very interesting, Kamel; any idea on how the Dynamic Data Display library performs on large data sets?  And does it, by any chance support zooming?


Jul 19, 2009 at 7:15 AM

Please have a look to the project!!! You can download 1 million points in less than 10 secs! And zooming is not a problem!

2009/7/18 EeeeEfff <>

From: EeeeEfff

Very interesting, Kamel; any idea on how the Dynamic Data Display library performs on large data sets?  And does it, by any chance support zooming?


Read the full discussion online.

To add a post to this discussion, reply to this email (

To start a new discussion for this project, email

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at

Feb 22, 2010 at 5:42 PM

I am having difficulty using the chart in this toolkit for real time data visualization.

As an example, I have an area chart that has seven series in it. Each series uses an in-memory collection for its source of data; each collection has about 22 elements that are X/Y coordinates. This is small set of data by almost any standard.

When I update the data on just one series at the rate of once-per-second by setting the series’ ItemSource property, my CPU usage for the application rises from 1% to an average of 12-15%, and occasionally spikes to the 20s. If I set all seven series in a single method that is called at once-per-second, I see an average CPU usage of 60-65% with spikes as in the 90s. Reducing the interval to as little as once every five seconds didn't seem make much impact on performance either.

I have verified through code isolation that setting the ItemSource property is what is bogging down the CPU. I have also used the WPF Performance Suite (Wndows SDK)  to verify that it is in fact the chart control that is responsible for the usage during that time.

Based on this, I don’t see how it could be used in a lot of “real time visualization” scenarios such as instrumentation applications—especially where larger sets of data might be required, multiple charts per screen, and/or other applications need to be running in the background.


Feb 24, 2015 at 6:44 AM
I am looking for exploded 3d pie chart like the one available in Office.Interop dlls. I saw that latest toolkit doesn't include this.
Niraj Bhatt