Several weeks ago we announced that we are currently working on a first-class charting solution for Windows Phone 7. Our primary goal – as with every single component – is to deliver highly-performing, pixel-perfect component with an intuitive and easy-to-use public API. Today we are releasing the first BETA of RadChart for WP7 and we are excited to share that our goal has been successfully completed so far – RadChart not only performs well, it is actually the fastest charting component available for Windows Phone 7.
Being well familiar with all of the Windows Phone internals and cave-eats, and possessing extensive Silverlight knowledge and experience, we did an in-depth research before even starting the development process. As I explained in this blog post, when performance is crucial you have to go beyond the platform standards and squeeze every single millisecond from the CPU and GPU. All I may say is that this research paid well…
But how are we sure claiming that our chart is the fastest available? Well, we did a thorough performance testing with three of our competitors and their charting solutions. For the sake of fair competition I will not mention their names and will list only the test results.
What we performed as a test was visualizing 100 data points by a simple Line chart. The chart was the only control on a blank page. Point markers (templates) were removed, so a plain multiline was to be rendered. Ticks and Labels were adjusted with the same step for each chart so that no advantage was brought to any of the test participants. Each chart was data-bound to an observable collection of business objects and bindings were specified to tell how point values are retrieved. The X-axis values were DateTime structures with 500 milliseconds interval between each of them and the Y-axis values were simple doubles. Every 30 milliseconds the first business object was removed from the collection and a new object with randomly generated values was added at the end of the collection. With this simple test we verified several aspects of the overall component performance:
- Loading time before the chart is completely visualized.
- Memory footprint.
- Frame rates per second – both of the Compositor and the UI threads.
And here is the comparison table (the test was performed on a Samsung Omnia 7 device):
| || Loading time(ms)* |
| Frame rate(GPU/CPU) |
| Texture Memory(KB) |
| Telerik || 793 || 12-13/12-13 || 2881 |
| Competitor1 || 2149 || 9-10/9-10 || 2864 |
| Competitor2 || 2226 || 3/3 || 2886 |
| Competitor3 || 2843 || 0-1/0-1 || 4613 |
| Competitor4** || 731 || 5/5 || 2796 |
| Competitor5** || 1021 || 3/3 || 2830 |
| Competitor6** || 4103 || 0/0 || 2886 |
*We started a System.Diagnostics.Stopwatch in the constructor of the page and waited for the first CompositionTarget.Rendering event. The watch was then stopped asynchronously (using Dispatcher.BeginInvoke) for more fair results because one competitor was actually rendering its series asynchronously after page load.
**These are new participants, added after the initial post was published
Analyzing the results
- Loading Time:
We are second here (taking about 60 milliseconds more) but still, our frame rate is nearly 3 times more than Competitor4's one.
- Frame rate:
Frame rate is a very important measurement and we are the undisputed leader here. Competitor1 was close to our results but still, 3 frames per second are quite a big advantage in the mobile world where resource are fairly limited. An interesting thing to point here is that leaving the test running on the device for about 20 minutes dropped Competitor1’s frames to about 3 per second. The slowest one is Competitor6 with about one frame per 4-5 seconds.
Competitor4 wins the battle with about 80KB less. This difference however is mainly because of our stand-alone generic chart layer (the view model built behind). This layer is a very important part of the chart as it is totally platform agnostic and allows the component to be visualized on different UI platforms like ASP.NET or Winforms. All of the competitors’ charts are native SL controls without this additional layer. Still, even without this generic layer, 80 Kilobytes may be easily skipped from the overall measurement in a world where applications’ memory is measured in Megabytes.
We are really excited about this BETA and bringing all the new stuff to you. Besides the charting component, which on its hand is an entire framework, we are also introducing a brand new Calendar control and several data virtualization mechanisms for our DataBoundListBox. Do not hesitate to grab your copy today and test the new goodies for yourself. Give us your feedback and you may win one of the 20 free licenses we are giving away – more information from our marketing team.
Update: test project added
After some discussions we decided to publish (download available at the end of the post) the sample project that performs the actual testing. Since we cannot distribute competitors’ assemblies with this test project, you will need to download the trials from their web sites. In order to compile the project locally you will need to:
- Download the trial version of Visiblox (Competitor1 in the comparison table) and add a reference to “Visiblox.Charts.dll”.
- Download the trial version of Mindscape (Competitor2 in the comparison table) and add a reference to “Mindscape.PhoneElements.dll”.
- Download the trial version of Visifire (Competitor3 in the comparison table) and add a reference to “SLWpVisifire.Charts.dll”.
- Download AmCharts QuickCharts (new test participant) and add a reference to “AmCharts.Windows.QuickCharts.WP.dll”.
- Download the CTP version of ComponentOne (new test participant) and add references to “C1.Phone.dll” and “C1.Phone.Chart.dll” libraries.
- Download the trial version of Syncfusion (new test participant) and add a reference to “Syncfusion.Chart.Phone.dll”.
Each competitor is evaluated on a single page and you will need to change the start-up page of the application in order to run each test – open the WMAppManifest.xml (residing in the Properties folder of the solution) file and change the default task of the application. Please, note that the loading time is affected by the trial messages displayed by some of the competitors; hence the results will vary, depending on how quick the message box is closed. That is why we divided the loading time in two parts – until the LayoutUpdated of the page is received and until the first CompositionTarget.Rendering notification is received.
We will be more than happy to hear your feedback – if you feel something is not set-up correctly, please let us know and we will update the test with the desired settings.
Our RadChart component is released, just go and check out all features which Telerik Windows Phone Chart has!