For the purposes of a recent production, I had to design a control named PieProgressBar. This class inherits RangeBase and as such has all the capabilities inherent in this type of control. It behaves in the end like any type ProgressBar control with a few more things. The hard part was to create dynamically pie in C #. Unlike WPF, Silverlight does not allow to override method to create new kinds of Shape. In other words, even if Shape is an abstract class, it is useless to inherit because the method of route design can not be overloaded.
The other technique is to use the "Path mini language" for creating geometric shapes in XAML. I had to use 3 segments with a ArcSegment to achieve this control. as I could not create primitive Pie for the designer in Blend, it took cunning ... The technique involves creating a pie chart dynamically when assigning a control part (ControlPart). Internally, the properties of filling the route generated, are related to properties of the control via a simple data binding created in C #.
You can see some examples below and download the library tweenedcontrols here.

Once the dll referenced, you can instantiate the control PieProgressBar in Blend through the Assets panel as shown below:

This component will probably be included as others in the CodePlex project SLExtensions. Thierry Bouquain updates it at this time and I welcome the move

Recently, I had to use Silverlight shaders for my personal needs, that article explains memory and CPU usage when you define shaders on objects.

First, each time you apply one of the shaders provided by default (DropShadow and Blur)  on a UIElement, actually you generate two bitmaps into RAM at runtime. The first bitmap is a simple rasterization of the UIElement, the second bitmap is that bitmap with the effect applied to it. In terms of performance, that behavior, wich is logic, can lead to some issues if you don't take care about few points :

First, we can calculate the memory used by an effect applied to a 200 * 200 UIElement. We consider that each pixel (40000) are encoded into 4 bytes :

• Alpha is coded on 1 byte (called octet in french) and 8 bits, leads to 256 possible values from 0 to 255 or 0x00 to 0xFF in Hexadecimal
• Red | 1 byte | 8 bits | 0xFF | 0-255
• Green | 1 byte | 8 bits | 0xFF | 0-255
• Blue  | 1 byte | 8 bits | 0xFF | 0-255

The first rasterized bitmap is contained by the RAM as it is made at runtime. As there's no compression for it you can calculate his weight with the formula below :
PixelsWidth * PixelsHeight * 4 Bytes = total weight of the intermediate bitmap in RAM

In our case the bitmap is about 160 Kbyte, but it's just the first bitmap. The second will at least take 160 kBytes plus extra size needed to render effect. The total size is about 400 kbyte if you consider that these effect create a bigger  rendered surface area than the original bounding box does.

Concerning customs pixels shaders, the behaviors is slighty different as there's a direct rasterisation wich creates by the way, a single bitmap into memory. This is a pretty good advantage in terms of memory usage but CPU usage increases. Indeed, the intermediate bitmap is here to aleviate CPU as it avoid to calculate it each time for translate transforms. When you translate an UIElement wich displays an effect, the intermediate bitmap is not recreated. For other operations, it is always regenerated. For example, if you decide to animate the scale or rotation or skew of a rectangle, the intermediate bitmap will be recreated each time. For a 60 max fps, Silverlight will create about 60 intermediate bitmaps and 60 bitmaps with final effect. Designers and developers must take care about that, as memory and CPU charge could increase drasticly and reduce performances... To avoid or limit that behavior, Microsoft has limited the max size of an effect to 2048 pixels for width and height.

All bitmaps, including intermediates, hang around for the life of the Effect+UIElement pairing. When the Effect is removed or a UIElement destroyed, all surfaces are released at once. CacheMode (bitmap cache) or 3D usage will create intermediate bitmaps in every way.

Jason Prado in charge at Microsoft on that topic kindly helps me to clarify some Silverlight behaviors concerning shaders. You will find some best practices below :

* Smaller area is better.

* The most important thing is to not trigger rerasterization of a UIElement. Rerasterization means we have to run the effect again, and both of these steps are expensive. Many changes, e.g. changing the color of a Rectangle, trigger rerasterization.

* Don't run effects on elements that change every frame. Trigger rerasterization as rarely as possible..

* BlurEffect is slow. It's a separated two-pass gaussian blur, but it is still an inherently slow operation if you want visual quality that is at all passable. Keep the radius low. At Radius >= 10, you start to notice serious performance degradation.

Hi, I recently have to find a solution create two customs controls

I recently needed controls customizable type ColorPicker ColorChooser and, finding none, I have designed from scratch, here's a demo.

They are in beta but I think provide a final version by November 15. In the meantime, if you want to test those controls and download the dll to test in SL3 is here.

Ps: the Silverlight plugin for wordpress provided by  Tim Heuer, is powerful and useful, so thank you to him, I will only use this solution from now.

You can find here the visual behavior of penner's equations, you will notice that some missing. You can find TweenedEquations here.

I put online Version 2 of Tweened. Tweened is an open-source CSharp 3 Animations generation library more oftenly called Tweens. Tweened is licensed under GNU General Public Licence v3.

The main purpose of this project is to provide a very simple way to animate any Xaml Objects you want in Silverlight 2. To reach this goal you just have to Reference Tweened.dll in a Silverlight 2 project. You will have access to color, RenderTransform and simple propertie Animation easily with many options like AutoReverse , BeginTime , SpeedRatio,etc... It's released and maintained for Silverlight 2 or higher. In layman's terms, Tweened helps you move things around on the screen using only code, instead of the timeline. The general idea of a tweening Class is that dynamic animation and transitions (created by code) are easier to maintain and control, and more stable than animation based on the regular Silverlight timeline. The Tweened syntax is created with simplicity of use in mind, while still allowing access to more advanced features. the general idea is to make doable the automatic creation of Storyboards resources type. Internally class Tween operates two Storyboards, the first is used for animation to go, the other is used if necessary to animation back. Storyboards Each of these contains a number of objects DoubleAnimation XAML. They serve as animated sequences. Each DoubleAnimation refers to an Xaml object and a lively targeted property, for example X or ScaleX. So a tween can animate lot of objects in several different equation of movement with different duration and behavior. For example a double animation could loop. URL :: http://library.tweened.org/ Online Documentation :: http://library.tweened.org/doc/html/ Chm Documentation :: http://library.tweened.org/doc/Tweened.chm