Hi,
After some time benchmarking this xaml I would like to point out the following things.
I see that there are still
opacity groups in the *no_opacity.xaml. It is very important not using this feature without knowing its implications. For example, in the following XAML:
<StackPanel
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Background="Aqua" Width="500" Height="500">
<Rectangle Fill="#FFFF0000" Width="100" Height="100" Opacity="0.50"/>
<Rectangle Fill="#80FF0000" Width="100" Height="100"/>
</StackPanel>
Although the aspect of both rectangles is the same, the first one is being rendered to a offscreen texture and later being copied to the main surface. It is very important not using this kind of opacity when there is only a single node (like in this example). In these cases is better transferring the alpha to the brush, like shown in the second example. We could detect and optimize this case in the future but it is better not relying on it.
The next thing I see in your xaml is that there is text that is not being rendered using fonts. It is being rendered using triangles. Is this intentional? Whenever possible, fonts should be used because they are very optimized for rendering at different resolutions.
As a general rule, the minimal number of paths must be used. If you can collapse several paths in the same one, it will improve render performance. Do this whenever your content allows it. If you can't collapse several paths in the same one, it is a good idea having each path one after another in the xaml. This will ensure that if they are using the same shader they will batch. For now, our batching algorithm is not able to reorder elements (will do in the future) so any reorder you can do in the xaml will help always. The rules for batching are (may change in the future):
- Paths with solid color brushes always batch. Solid color is the fastest brush. Use it whenever possible.
- Paths with linear brushes batch if they are using the same ramp.
- Paths with radial gradient only batch is using the same radial brush settings (not only ramp)
- Paths with image brushes batch if the images are in the same texture (atlased).
Next point, you are not using resources. For example, although you are using the same gradient in several paths, it is not being shared. This is an important factor to reduce memory but it is also important to reduce rendering performance because it allow us to improve batching. The same for the Path.Data. Using a resource here, you can share paths very easily. Using resources in Blend is very easy, you only have to click on the white dot of the resource and select "
Convert to New Resource...".
We are improving the XamlPlayer to give better information about performance. Probably new features will come in v1.1.3, but for now there are two hidden tricks in the XamlPlayer that can be very useful: pressing CTRL+B displays batching infomation and CTRL+M show when masking is being used (I see by the way several uses in your xaml that I think is a bug in our side. We are investigating it).
Having said that...
the main bottleneck in your xaml is the GPU doing multisampling. At least, in my machine (a notebook with an integrated Intel Card) I am getting 100fps with 8x and going to almost 200fps with no multi sampling.
What resolution and hardware are you targetting? We have a mode that emulates multisampling (PPA). Have you tried it? We are working on it for this version (I client asked for it, and it was time to revisit the algorithm because there are several rendering glitches that can be improved).
