User avatar
matt.rudder
Topic Author
Posts: 21
Joined: 24 May 2013, 08:12
Location: San Francisco, CA
Contact:

Understanding Batching and Rendering Performance

28 May 2013, 21:29

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:
<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>
Any sort of best practices or tips for efficient rendering to keep in mind when developing UI?
 
User avatar
matt.rudder
Topic Author
Posts: 21
Joined: 24 May 2013, 08:12
Location: San Francisco, CA
Contact:

Re: Understanding Batching and Rendering Performance

28 May 2013, 23:07

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. :P
 
User avatar
jsantos
Site Admin
Posts: 2904
Joined: 20 Jan 2012, 17:18
Contact:

Re: Understanding Batching and Rendering Performance

29 May 2013, 03:05

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 :
  • 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
This mechanism cab be (and will be improved in the future) by trying to collapse linear and radial gradients with different ramps (by using atlases for the ramps, that now are passed compressed in dynamic textures) and the algorithm in charge of doing the swaps commented above is quite limited for now because it takes CPU and on mobiles this is a scarce resource. We decided to leave this optimization for v1.1.

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: Google [Bot] and 1 guest