When using vector graphics for our UI we've noticed a significant performance hit (our framerate dropped from 600+ to about 30). I understand that rendering vector assets is more computationally intensive so my question is does Noesis have any built-in way to mitigate this? WPF seems to have the ability to cache a canvas to a bitmap (http://msdn.microsoft.com/en-us/library ... 10%29.aspx) though BitmapCache does not seem to be supported in Noesis. Are there other built-in ways to improve performance while still using vector art?

Hi,

We don't support BitmapCache yet, although you can do it manually, you can render to texture and save the content for future usage. Although yes, it can be a little bit tedious.

Could I have a look at your xaml? (send me in private if you want) I would like to see if it can be optimized. The first cause of inefficiency is the abuse of Opacity Groups. In many cases they can be avoided (we are preparing a document commenting about this and about our batching mechanism, that by the way, it is being improved for future versions)

I am sending you two versions of a file that is giving us some performance issues via email. One version is the original and the other is with all opacity removed. The latter gives a notable increase in framerate, though we are still under where we would like to be and we are still see a drop from the 600+fps range (UI disabled) to about about 75fps.

I could implement a cache myself as a lot of the UI is static, it was just something I had hoped to avoid if there are methods built into the system.

We also noticed that when viewing our UI in the XamlPlayer most of the Rendering Stats are 0. I also queried the stats in game using IRenderer::GetStats() and the data returned is all 0. Do you know why this might be?

Thanks for your help.

Hi,

As soon as I receive the missing resources I will start the investigation and tell you.

Yes, stats are broken (disabled) in public builds. It is a known issue we are going to solve.

Thanks!

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:
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).

Wow, thanks for all the feedback!

We'll work on restructuring based on your guidelines and I'll post again when we have some results.

To answer some of your immediate questions though, the text not using a font is intentional. We'll be reorganizing that as well based off of the suggestion in this thread (http://www.noesisengine.com/community_f ... ?f=3&t=241).

We're targeting 1080x1920 (yes, it is portrait) but we'd obviously like to have a crisp look at higher resolutions, hence the vectors. Previously I had been running in a 720wide window. We aren't really targeting
specific hardware as it is a PC application. We're just trying to strike a balance between looking good and running smoothly.