Now, when I play the game,
we'll get some information coming in through here.
UI details is going to be fairly empty right now. That's fine.
I'm just going to go ahead and select one of these frames.
In fact, I'll select one of these larger ones here,
and then here, you get all the details as to how things are actually being batched.
You'll notice that under our canvas,
there are three different batches.
Now, if we scroll over here to the right or we just make these a little smaller,
we can see that each successive batch
gives a reason for why it did not batch with the previous.
In this instance, we just have different materials.
If you're able to reduce the number of materials that your UI is using,
you'll make your UI operate just that much better.
We have a fairly simple UI going here,
and there is a few different reasons that batching could be broken.
First of which is a non co-planar UI element,
meaning that a UI element that is not in the same rotation as the canvas.
This means that the game has to figure out how to
draw it in a 3D rather than 2D perspective.
The other reason is an injection of a new canvas group.
It's generally a good idea to avoid canvas groups where you can,
they tend to have a bit more overhead to them.
I've gone ahead and added a button to
our canvas just to show off something in the UI details that is useful.
You'll notice it's not a lot happening down here.
If I go ahead and click on that button though,
we get something called a marker.
That marker tells me exactly what was
clicked and what the button on click was called.
The other tool we have at our disposal is a frame debugger.
Now, this can apply to the game at large,
not just UI, but UI is an element of it.
If you go to Window, Frame Debugger,
just going to put that right there, if you enable it,
you're going to start gaining information as to how your game
is actually drawing everything that you see.
Now, under camera.render, we're going to get basically the entire game being constructed.
And there is another path for our render camera,
so that's not for free.
At the very bottom here,
we've got the UGUI rendering
and what this does is it will show you step-by-step how these things were drawn.
Notice that the very first draw call is for our radar background.
The rest, it comes in at the next draw call for our text,
and then the next three draw calls are for our button.
So, the buttons can have a bit more overhead than the regular item.
It depends on how you are rendering them,
the text is part of our button as well.
The button here is taking up three draw calls.
It's a little bit more expensive but we do have a different piece
of text on top of the button so this is to be expected.
Furthermore, on the right here,
you can see some of our shader properties giving us
an idea of what the shader is doing to make this thing work.
If you're running into render issues related to your UI,
go ahead and have a look at your Profiler with
the UI elements enabled or the Frame Debugger.
They'll probably give you a good idea as to what's breaking
your batches or what's causing a lot of extra draw calls.