I’m hoping to get some official clarification on draw calls and how to minimise them.
I had a UI set up in DFGUI that consumed 2 draw calls - one for the sprites, and one for the text.
After recreating the same UI in 4.6, it consumes 45 draw calls.
Everything is atlas’d although I have two atlas groups (presumably because one has gone over a predetermined size limit - they are all in the same format with the same tag).
I notice a lot of strange behavior - for instance, most of my UI panels are moved outside the canvas until I activate them, after which they slide in. However, my draw calls actually go down by 10 when the main menu slides in - shouldn’t the opposite behavior be demonstrated?
Is the text elements affecting the draw call count, and how they are stacked with sprite elements?
I noticed my draw calls in DFGUI are so low because they have an option called ‘Merge Materials’ which reduces the total count from 55 down to 2. In the absence of such an option in 4.6, I’m trying to figure out how to manually manage my scene elements to keep draw calls to a minimum. There’s a general lack of information on draw calls in the new UI system so I’m hoping we can generate some best practice type discussion.
just guessing here but the element off screen are likely what are breaking the batch as they are overlapping each other. The batch still counts outside of the canvas area.
Hi Phil, just to clarify, are you saying that UI elements that overlap don’t combine their draw calls?
EDIT: I made a few tweaks (such as setting all textures to Advanced’ and the Mesh Type to ‘Full Rectangle’) and I’ve got the draw calls down to 25.
Overlapping definitely seems to break batching though - when a menu slides in, it passes over a UI border element at the top of the screen. During the time it is passing over it, the draw calls go from 25 to 38 for a brief moment.
The odd thing is, I can’t seem to be able to reduce the draw calls from 25, even when elements don’t overlap - if I hit play and then move all the UI elements off screen and non overlapping, it doesn’t reduce the draw calls - they are still stuck on 25.
This leads me to believe that overlapping is an issue, but there are also more things at play here than just that - any other known things that can break batching?
well batching can only be done for elements that share a texture/ material. Make sure you have the sprite packer turned on (if on pro) or you have packed your own sprites.
Text also is a majour cause of extra DC as they are on a separate atlas which causes the extra batch.
everything is definitely packed onto one atlas using the sprite packer.
Text and overlaps with images does indeed seem to be the main issue - I can have as many images and text as I want and it only creates 2 draw calls as long as there are no overlaps.
I can also have overlaps without additional draw calls as long as ALL the text elements are either in front or behind ALL the images.
It’s only when I start layering text and sprites that the draw calls go up, with the worst case scenario being a layered text-image-text-image-text type scenario, which results in 1 draw call for each element.
I guess I’m trying to understand if there’s any way to prevent this behavior - I might be assuming here, but I would imagine that any semi-complex UI will have a LOT of elements, both text and sprites, all nested in various ways under a root canvas - it seems almost impossible to avoid having layered text and images in some form.
using the default system yea it will create a bunch of draw calls when overlaying the text and images. Unfortunately not much we can do about that. One possible solution you might want to try (not saying it would work as just thinking out loud) would be to generate your own atlas with a bitmap font and all your images together. That way its all one atlas and can be batched down to 1 DC.
well a bitmap font is just a definition file and a atlas. so i think you should be able to put things together. But again just was thinking out loud without physically trying it.
Interesting… any plans to have internal tools to generate bitmap fonts from a font file and add them to an existing atlas? I’d imagine that this is something which would benefit a whole bunch of users - pretty much everyone developing for mobile in fact!
For us its a real step backward to think in those terms as we worry about translations.
In theory so long as text is overlaid there is no reason it should ever cost more than one draw call. If the text is under and over then I can imagine sorting with separate atlases causing more draw calls. As it is in a typical UI with text on top - it should be 2 draw calls for everything in total.
with those draw call issues the new UI is absolutely worthless!
Going back to NGUI!
to be clear i am using unity 4.6.1p5
an the issue states with the scroll rect
scrolling is very common in mobile, and if it can’t handle that conveniently it is just worthless
