As you might have already read Valio’s blog or have stopped by our booth at MIX11 and seen our WP7 demos, we are currently focused on delivering a highly performing charting solution to our users. As with every control or feature we are aiming high - exceptional performance, intuitive and easy-to-use model and pixel-perfectness are some of the major tasks we have setup. We have spent literally months of research, starting from high-level concepts, chart domain knowledge, architecture and ending with implementation details like logical trees, extremely fast home-grown property store and entirely custom layout system. Every single detail has been verified through a spike project and pros and cons of different approaches were thoroughly evaluated. The final result – we have successfully implemented the core of RadChart for WP7 and early bits are being demoed at our booth at MIX11. Do not miss to visit us and see the demos for yourself.
Why are we so fast?
Having 8 Gigs of RAM, 4 cores at 2.67 GHz and one of the latest video adapters sometimes results in writing sexy rather than efficient code. When you practically see no difference between O(n) and O(5n) complexity (both linear though) then you may opt for LINQ chains rather than writing your own loops. Same with the architecture – if DependencyObject’s look-up speed is satisfactory and you see no reason to implement your own property store then why should you do so? Or if ItemsControl is fast enough to suite your scenario then why should you bother with writing your own panels? Having your own logical tree – hell no, why do we have Logical and Visual trees in SL?
Well, all these points make perfect sense in the context of Windows Phone 7 where hardware resources are fairly limited. To sum up:
- We have separated the chart into several layers, where the core one is totally platform agnostic and is built on top of our custom logical tree. We call this layer the “View Model” of the chart.
- We have a custom property store used within the charting logical tree. It is about 5 times faster than DependencyObject in look-up time and consumes about 3 times less memory.
- We have an entirely custom layout and do not rely on the SL layout system to arrange our charting view models.
- We have a stand-alone visualization layer that presents the chart view model. Every view model is presented by the simplest possible SL visual – e.g. Rectangle, Line, Polyline, etc. Still, every single aspect is fully customizable by specifying Data Templates or Styles.
- We use Canvas – the only SL panel that does not invalidate measure automatically. When a redraw of some charting part is required, we simply update the Width, Height and Canvas.Left, Canvas.Top properties of the corresponding visual. A simple test proved that calling InvalidateMeasure of the canvas upon a change the in view model degrades performance about 10 times.
Using Canvas with a custom layout rather than the standard layout panels in SL may result in floating-point rounding errors that produce visual glitches. Well, not in our chart – a layout pass arranges every single node in such a way that it occupies exactly the desired amount of pixels on the screen.
We plan to release the first BETA somewhere in the middle of May. At that time the chart should be close to its final version regarding functionality and object model but without interactivity – e.g. zooming and scrolling. Another BETA with complete interactivity will be released near the end of June. The official release will be somewhere in the middle of July.
We are looking forward to hearing your thoughts, suggestions and feature requests. Do not hesitate to share your feedback – it will help us to deliver an even greater product.