-
- matt.rudder
- Posts: 21
- Joined:
- Location: San Francisco, CA
- Contact:
Understanding Batching and Rendering Performance
Is there any documentation available that might allow better understanding of how the draw batching works with NoesisGUI? I'm building some simple UIs and the draw calls seem higher than I would expect.
For example, this basic layout with a single border text block generates 6 batches when zoomed in, and 4 when first loading the scene in XamlPlayer:
Any sort of best practices or tips for efficient rendering to keep in mind when developing UI?
For example, this basic layout with a single border text block generates 6 batches when zoomed in, and 4 when first loading the scene in XamlPlayer:
Code: Select all
<Grid
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
d:DesignWidth="960" d:DesignHeight="640"
mc:Ignorable="d" Background="Transparent">
<Grid.Resources>
<LinearGradientBrush x:Key="ButtonBrush" StartPoint="0,0" EndPoint="0,1">
<GradientStop Color="#6A6D50" Offset="0" />
<GradientStop Color="#494C2F" Offset="1" />
</LinearGradientBrush>
</Grid.Resources>
<Border Background="{StaticResource ButtonBrush}" Width="200" Height="48" VerticalAlignment="Center" HorizontalAlignment="Center">
<TextBlock Foreground="White" FontSize="20" FontWeight="Medium" Margin="28,12,28,0">BUTTON</TextBlock>
</Border>
</Grid>
-
- matt.rudder
- Posts: 21
- Joined:
- Location: San Francisco, CA
- Contact:
Re: Understanding Batching and Rendering Performance
Also, what does the "Resources Created" stat equate to in XamlPlayer. It just seems to keep climbing, wanted to make sure I'm not just leaking memory like crazy. 
Re: Understanding Batching and Rendering Performance
Hi matt,
For now the batching mechanism works this way: each frame, nodes of the tree are iterated and asked for their primitives. Before rendering we have a list of primitives like this:
[A,B,C,D,E,F,G]
If two primitives next to each other can be "collapsed" (more on this later) they are joined, for example:
[A,BC,D,E,FG]
And later we try to swap node positions (for those that are allowed) to get more unions. For example, imagine that the group FG can be swapped by D (because its bounding box does not collide with D nor E) and that BC and FG can be collapsed. Then, we would have:
[A, BCFG,D,E]
resulting in 4 batches.
Actually the rules for being "collapsed" are :
The explanation of your 4 batches for your sample: one batch is for the radial gradient, and 3 batches are needed for rendering the text because for default we use an antialiasing algorithm (similar to this https://www.grc.com/ctwhat.htm) that use a pass for each RGB component. This algorithm is disabled as soon as you zoom in the xaml. And this explains why batches change to 2 in that situation. I am not getting 6 batches if I zoom in, but probably what is happening is that your level of zoom requires big glyphs and they are being rendered to different atlas textures. One unsolved problem we have now is that big letters are not render with triangles, but instead a texture is used. This will change in the future. By the way, the LCD antialiasing algorithm is disabled on mobiles.
With respect to the Resources Created stat. It is obsolete and incorrect. Will be eliminated in the next version.
Yes, we have to make a decent document with all this and more information for optimizing content (for example, opacity groups (render to texture) do have great cost on mobiles.
For now the batching mechanism works this way: each frame, nodes of the tree are iterated and asked for their primitives. Before rendering we have a list of primitives like this:
[A,B,C,D,E,F,G]
If two primitives next to each other can be "collapsed" (more on this later) they are joined, for example:
[A,BC,D,E,FG]
And later we try to swap node positions (for those that are allowed) to get more unions. For example, imagine that the group FG can be swapped by D (because its bounding box does not collide with D nor E) and that BC and FG can be collapsed. Then, we would have:
[A, BCFG,D,E]
resulting in 4 batches.
Actually the rules for being "collapsed" are :
- All solid paints can be collapsed
- Linear gradients with the same ramp can be collapsed
- Radial gradients with the same ramp can be collapsed
- Images (including glyphs) are collapsed if using the same texture
The explanation of your 4 batches for your sample: one batch is for the radial gradient, and 3 batches are needed for rendering the text because for default we use an antialiasing algorithm (similar to this https://www.grc.com/ctwhat.htm) that use a pass for each RGB component. This algorithm is disabled as soon as you zoom in the xaml. And this explains why batches change to 2 in that situation. I am not getting 6 batches if I zoom in, but probably what is happening is that your level of zoom requires big glyphs and they are being rendered to different atlas textures. One unsolved problem we have now is that big letters are not render with triangles, but instead a texture is used. This will change in the future. By the way, the LCD antialiasing algorithm is disabled on mobiles.
With respect to the Resources Created stat. It is obsolete and incorrect. Will be eliminated in the next version.
Yes, we have to make a decent document with all this and more information for optimizing content (for example, opacity groups (render to texture) do have great cost on mobiles.
Who is online
Users browsing this forum: Bing [Bot] and 9 guests