Approaching Silverlight development is a rather daunting task as it seems to require a rather different mindset to work I have done in the past.
I have been working on it for several months and we have already released an application that presents form-based pages. So I have the basics of XAML for layout but what I need to do now is move into graphically representing data. For example transform a list of objects representing vehicle speed recordings into a line graph of speed. I am at a loss on what the best way is to approach this.
Can anyone point me to articles or tutorials that present this kind of thing?
Your first port of call for Silverlight learning should be the official site http://silverlight.net/Learn/
If you want to do any data visualization/charting then first try the Silverlight Toolkit on codeplex. It's fantastic if you want to get anything up and running quickly.
Also check out Delay's Blog on charting and the chartbuilder code
Bang your head against it for 3-6 months. That's how I did it and it's worked out pretty well so far.
But seriously, the learning curve sucks.
There's charting libraries for Silverlight out there, you could grab one of those but I wouldn't waste money on it. It's relatively easy to write this kind of code yourself.
All you really need is a DrawingVisual. Once you have that you can render what you need on to it's surface. The trick is to make sure that you have sufficient layout information when you render. Because this is vector graphics, you can use the ScaleTransform to match your content bounds instead of repainting on size changed. Other than that, you'll wanna host your DrawingVisual in a UIFrameworkElement and let the dimension of that object govern where and how you draw your data. This will give you all the layout goodness of WPF/Silverlight.
For drawing there are plenty of Geometry classes you can rely on but there's one thing that you'll wanna do and that's to adjust the level of detail in your data points with respect to your drawing. This is the number one trick to make sure you don't hog the CPU.
Avoid drawing more than one data point per pixel. If you have a lot of data points, and a small drawing surface you can use a rolling average to smooth the result.
If you approach this with the above things in mind you should be able to write a flexible graph UI element that you can visualize data with, in no time at all.
I did this in a WPF application, I'm pretty much assuming that you can do the exact same thing with Silverlight 2.0, you'll just yell at me if you cant?
Related
In our WPF application, we have a need to display about 64 real-time level meters for an audio application. The tests we've thrown at WPF, even when rendering basic primitives as efficiently as we can still show it to be nowhere near where our application needs to be, often times bogging down the main thread so much to the point that it's non-responsive to input.
As such, we have to go with something more optimized for graphics performance such as DirectX (via SlimDX or SharpDX) or OpenGL/ES (via Atlas which converts it to DirectX calls.)
My question is if it's possible to create multiple, small DirectX-based areas, each representing an individual meter, or for that matter, is that even the right approach? I was under the understanding that you have to run it as at a minimum, the entire window, not a portion thereof.
The issues I see with the latter are airspace issues wherein you can't have WPF content in front of DirectX content in the same window, and we really don't want to have to redo all of our controls in DirectX since for the other non-meter 95% of our UI WPF is great!
I have read that you can render DirectX to a brush, then use that inside WPF, or using the WriteableBitmap class which gives you direct access to the buffers WPF then uses in its Render thread, both of which don't seem to suffer from the Airspace issues, but that seems we'd be right back at the same place with WPF being the bottleneck since it still has to do the rendering.
We are of course going to dedicate a few weeks to sample applications testing all of the above, but I'm wondering if I'm even headed in the right direction, and/or if there are any caveats we can avoid by talking to people with experience doing something like this to avoid common pitfalls, etc. As such, any comments will be appreciated.
I'm hoping we can perhaps even start a wiki somewhere to discuss this topic as it seems to be a popular one, albeit spread all over the place making it hard for new entrants to get the information they seek.
With wpf / d3d interop, You should always try to create the smallest number of interop calls. So you should prefer rendering all 64 level meters in a single render target (also it allows you to batch your primitive rendering and draw everything in the smallest number of gpu calls).
you should try to use the D3DImage API that allows you to share your own D3D texture with the wpf renderer.
If WPF can't really handle these 64 moving bars, you could go with a single D3DImage and use Direct3D9 for rendering all bars at once directly to it. For your specific scenario, you shouldn't have any performance problem.
I'm trying to create a view in Silverlight that can display rounds in a tournament. At the moment I have a set of grid views side by side and each one shows all the people still in that round of the knockout.
What I am trying to achieve is a view that shows clearly who played who and when their next games. Something similar to the below. I'm just wanting some pointers in the direction of what control I could manipulate enough to achieve this as I am very much new to Silverlight.
If you're looking for components you can tweak to work this way, I would strongly recommend investigating some of the third-party components designed for creating diagrams and/or org charts. Some cost money, but in my experience, the cost of a third-party control is less than the cost of my time to reproduce it myself. Here are some links to investigate:
Free: (Most of these are vertical, but you could tweak them to meet your horizontal layout):
http://www.codeproject.com/KB/cs/Org_Chart_Generator.aspx
http://omourad.blogspot.com/2009/08/silverlight-organization-chart.html
http://www.sharpdevel.com/2009/12/organization-chart-free-control-in.html
Money:
http://nwoods.com/components/silverlight-wpf/goxam-overview.htm (<-- my personal preference)
http://www.mindfusion.eu/diagramlite.html
http://www.syncfusion.com/products/user-interface-edition/silverlight/diagram
Good luck!
I've been looking into Silverlight charting controls to display a large number of samples, (~10,000 data points in five separate series - ~50k points all up).
I have found the existing options produced by Dundas, Visifire, Microsoft etc to be extremely poor performers when displaying more than a few hundred data points.
I believe the performance issues with existing chart controls is caused by the heavy use of vector graphics.
Ergo one solution would be a client-side chart control that uses the WritableBitmap class to generate a raster chart.
Before I fall too far down the wheel re-invention rabbit hole - has anyone found a third party or OSS control that will manage large numbers of data points on a sparkline?
Check out Visiblox ( http://www.visiblox.com/ ) Charts. I'm working on a telemetry application at the minute which uses three of their charts in the same Silverlight component, plotting about 36,000 points in total, and there is very little slowdown in terms of performance, if any at all.
They have a high performance example on their website here - http://www.visiblox.com/examples/LargeDataSets. I chose to use Visiblox after loooking at the following blog post:
New performance comparison: http://www.visifire.com/blog/2011/12/02/fast-silverlight-charts/
Old performance comparison: http://www.scottlogic.co.uk/blog/colin/2010/12/visiblox-visifire-dynamicdatadisplay-charting-performance-comparison/
My telemetry example is now part of a CodeProject article that I have created, if you want to take a look!
Based on the recommendations here, I have just trialled Visiblox and Infragistics.
Visiblox has a good developer experience, clean APIs, no bloat. While the performance is OK for a few thousand datapoints, performance breaks down as you go into the 100k range. Here's the Visiblox sample with a few thousand points (you can download the sample and just tweak the number of datapoints).
Now, the common argument here is that you should not bind that much data to a chart anyway, but should do some trimming beforehand. I do agree with that, but ideally, I want a chart control that does take care of that for me. Getting Zooming, Panning and all that right are non-trivial tasks and I'd be happy to shell out a few 100$ to get that functionality. It's plain economic common sense to not reinvent the wheel here.
Infragistics certainly gets that right. I can bind a million odatapoints and get smooth peformance. Here's the Infragistics sample.
However, Infragistics installs a lot of junk (a local IIS web app with the samples you can also see online) and besides the (excellent) samples and the code-level documentation, I do miss some high-level introduction to each component and it's individual modules.
Since a lot of people on SO recommend Telerik controls for their clean APIs, Documentation and Developer Support, I did also take a look at their chart control. However, I must admit I find it rather slow (Zooming takes roughly 500-1000ms, which is too long to feel smooth).
Here's the Telerik sample.
Visifire is the fastest chart now. Check out the blog link below.
http://www.visifire.com/blog/2011/12/02/fast-silverlight-charts/
The Chart image says Visifire is 3 to 4x faster than Visiblox..!
Before you start playing around with WritableBitmap on your own take a look at WriteableBitmapEx from René Schulte, he blogs about it here. Awesome stuff.
I don't know of any OSS or 3rd party controls that'll do what you need.
The one case where I've had the need for 100K+ of datapoints, we made it work by keeping it simple. The biggest perf killer was the number of elements within each datapoint. By keeping the element a simple ellipse with a static brush fill the app was rather snappy.
Infragistics claims to be able to handle massive amounts of data in their recently released xamDataChart.
http://www.infragistics.com/dotnet/netadvantage/silverlight/data-visualization/xam-web-data-chart.aspx#Overview
I believe the Telerik sample you are looking for can be found here. It shows large amounts of data that you can actually zoom in/out of. They also have a Server Load "Performance" Demo as well. Here is an example of the Scatter Chart with hundreds of data points.
Have you looked at the Telerik charting controls? Here is a link to one of their demos where they are using 100.000 data points:
http://demos.telerik.com/silverlight/#Chart/Sampling
I should also mention that I have not used the charting controls myself, so I cannot vouch for them. But the demos look good to me.
EDIT:
The link above has gone stale. Here is a link to the latest incarnation of the Telerik charting control They call it ChartView now:
http://demos.telerik.com/silverlight/#ChartView/FirstLook
currently im taking a Master degree course in Computer Sciences, and i´d like to implement a Cellular Automata in WPF. The rendering performance must be enough to display
a lattice (grid) containing 200,000 cells.
Since updating visuals is very slow in WPF (due to the visual and logical tree), maybe it's better to use old good Picturebox (GDI+) to do the rendering and WPF to implement the rest of the software. A second option would be to use pixel shaders (HLSL), but i'dont know if WPF supports multi-pass shaders.
Let me know what you think.
First, check out the WriteableBitmap. The performance is decent, but nowhere near a shader can provide. I'm not exactly sure what kind of shaders are supported, but I'd think it wouldn't be limited...
Found this over on WindowsClient, it doesn't seem like multipass shaders are supported currently. Again, its probably just a matter of time and demand on that code; it may have been added since the article was written.
Somebody +1 me for not mentioning the Game of Life.
After reading the wikipedia article on WPF architecture, I am a bit confused with the benefits that WPF will offer me. (wikipedia is not a good research reference, but i found it useful). I have some questions
1) WPF uses d3d surfaces to render. However, the scenegraph is rendered into the d3d surface by the media integrated layer, which runs on the CPU. Is this true ?
2) I just found out by asking a question here that bitmaps dont use native resources. Does this mean that if i use alot of images, the MIL will copy each when rendering, rather than storing the bitmaps on the video card as a texture ?
3) The article mentions that WPF uses the painters algorithm which is back to front. Thats painfully slow. Is there any rational why WPF omits using Z-buffering and rendering front to back ? I am guessing its because the simplest way to handle transparency, but it seems weak.
The reason i ask is that i am thinking it wont be wise for me to put hundreds of buttons on a screen even though my colleagues are saying its directx accelerated. I dont quite believe that whole directx accelerated bit about WPF. I used to work on video games and my memory of writing d3d and opengl code tells me to be cautious.
For questions #1 and #3 you might want to check out this section of the SDK that discusses the Visual class and how it's rendering instructions are exchanged between the higher level framework and the media integration layer (MIL). It also discusses why the painters algorithm is used.
For #2, no that is most definitely not the case. The bitmap data will be moved to the hardware and cached there.
I tested that, I wrote two programs that show 1,000 buttons on screen, one in WinForms and one in WPF, both worked just fine.
I then pushed that up to 10,000 buttons, at that point the WPF app took a few seconds to start but run just fine, the WinForms app didn't start.
Win32 itself (and WinForms) isn't built for applications with hundreds of controls (believe me I wrote such an app), at some point it just stops working, WPF on the other hand, keeps working even if it slows down a bit at some point.
So, if you do need to put a lot of controls on screen WPF is your best bet (unless you want to roll your own UI framework - and you think you can do better than the entire MS perf team).
Also, WPF has many advantages other than graphics acceleration: richer graphics, drawing model that is easier to work with, animations, 3d and my personal favorite - amazing data-binding.
This will let you develop richer UIs faster - and I think that will make a much bigger difference than the painting algorithm used.
BTW, if you need to put hundreds of buttons on the screen this is likely to be a bad user experience and you may want to reconsider your UI design,