Performance of new UI

Hi, we are having significant performance drop while using the new UI and we are wondering if that's how it should perform or is it something that we are doing wrong. We are developing 3d racing game.

We now have benchmarked 3 scenarios:
1) Scene has multiple game objects with canvases, but all of them are disabled except the one in 3d view. The one in 3d view is not updated at all but it's visible. This gives us 60fps.
2) If we
Scene has 3d content and single canvas on top of that with 1 dynamic tacho control and 2 static texts. There are other disabled canvases in the scene (~50 of them, non of them were ever shown, but they are there). This gives us only 40fps. Mesh.CreateVBO adds 3ms, Canvas.BuildBatch ~1.3ms and .SendWillRenderCanvases() adds another 1ms.
3) If we remove all the canvases except the one on top of the 3d view, the framerate rises to 50fps, but that's still a 10fps drop caused by a single visible canvas that barely has any content in it.

Trying to build a clickable list using scroll rect (having ~10-15 buttons within the masked scroll rect) is even worse. If list is being scrolled the framerate drops to as low as 10fps. We haven't yet tested it with pixel perfect mode being off, but we don't expect that this single checkbox will add 50fps.

Is this expected performance and will this be fixed in foreseeable future? We love the new UI (we are using it since ~ beta 7), but if that's the expected performance, we unfortunately will have to switch back to using NGUI.

 

We are also seeing similar issues with the new 4.6 UI. Particularly the performance issues appear to occur around scroll rects. With a list containing 13 items (2 - 3 visible at any one given moment) and each item comprised of ~10 children we are getting ~10-15FPS on an iPhone 5s.

We have performed some profiling via Pro and don't see anything overtly obvious that we are doing wrong. We see a ton of time being spent in SendWillRenderCanvases(). The massive performance drop is unacceptable for us though and we are currently looking at moving back to NGUI.

The team absolutely loves the new UI system and we want to see this perform (and exceed) what we can get from NGUI currently.

Does anyone have experience optimizing the new UI system? or who could suggest some gotchas/roadblocks/landmines to avoid?

Thanks!!

 

Let's hope this thread will be noticed by Unity devs and maybe they can give some insights on the issue..

 

If you create a small reproduction for the community, I am sure some developers (not only the ones from Unity) will have a look at it. Many are greedy to improve the Unity UI and understand it better. All you need to do is to create a reproduction.

No one from Unity can most likely help you without a reproduction as well.

 

Hi Tim, thanks for the follow up. We will definitely check the patch out as soon as it's out.

 

After updating to p1 we see the performance improvement, but nothing that would make the scrollrect usable ... Also we didn't get much improvement in our game screen, updating few small items in one canvas is still very expensive: BuildBatch is 0.44ms, SendWillRender 0.63ms and CreateVBO 2.82ms.

 

We are also getting a drop in Framerate to 4 or 5 FPS when using the ScrollRect. Porting to Windows Phone 8. Testing in Lumia 530 and Lumia 1020. Noticed a slight improvement after updating to 4.6.0p1. Agree with Raimis that scrollRect is almost unusable.

 

Hey Guys,

What is inside your scroll rect, By any chance is it text?

We build to both android and IOS (not windows) and we have had no issues with scroll rects and they contain a huge amount of items.

Thanks,

 

I have just built a simple project on WP8 with only few items on screen and few items in scrollrect. I believe the problem is with overall amount of items in the view and the fact that whole scene gets recalculated. With ~10 items visible in screen and one of them in scrollrect we still get 60fps, but methods listed above take about 5-7ms. That is way too much given the whole ui is only 10 items and 500 tris. I will work on that project later this week, and will probably submit it to unity if I see performance issues.

 

I have the same problem.After adding new ui i have serious performance problems.Frame rate actually not effected too much but while playing, sometimes screen is freezing(guess some memory cleanup or something like this). When i disabled new ui and adding back to old ui performance problem has gone.(This performance problem can't seen on stand alone builds, i can see this in iPhone4 tests).

 

Heya,
Raimis in your experience do you know if the canvus size effects performance much? E.g. 512 vs. 256.

I'm building a rift game thus I need a ton of world locked canvas's, basically one for each separate button. I switched to the Unity GUI as I assumed native would be more permanent but I'm a bit worried based on this post.

Wish there were better performance guidelines in the docs.

 

Since we mainly use screen space overlay canvases I can't really comment on how canvas size affects performance, but for some reason I doubt if it has any affect at all.

 

Android. Performance on Xoom 2 ME: 1 Canvas with 2 overlapping fullscreen RawImage instances drop fps to 10-12... And to compare - game scene with 20k polygons (60+ animated models) (and old GUI) at 60 fps...

 

I am getting a huge performance hit with draw calls. I have a scrollRect that contains 53 children, each child contains 2sprites + text

That is around 150 UI elements

Enabling and disabling this is a huge performance hit, leaving it on off screen on the other hand constantly draws all the elements (300+ draw calls)

I have tried using the sprite packer. This took me down to 200 draw calls... still not functional for mobile.

Please implement a system where I can set culling layers for the canvas so that items that are not in use can be culled instead of disabled/enabled.

 

I have read somewhere that currently Canvas does not support culling. I believe this is on TODO list for Unity

 

I managed to solve my problem partially. I brought the draw calls down - the issue was that the sprites were overlapping each other. The moment two RectTransforms overlapped they would no longer batch properly. Seperating them a little more took me from ~200 draw calls to somewhere around ~30.

As for the culling - I am now experimenting with seperate canvases for each major view - this way I can just change the layer of the canvas and have my camera cull it out of the view to save on drawcalls.

 

I'm suffering a similar case. I have a ScrollRect containing about 200-300 elements with both text and sprites (about 5 screens, vertical scrolling only). The affected screen is GUI only, no 3D or heavy elements are drawn.

The result reaches 60 fps with no scrolling, as I'd expect, but as soon as a scroll starts, performance drops to the 10 fps range. I understand the GUI system was not designed for this scenario, as the profile reveals it needs to rebuild dozens of batches each frame in order to move the elements around. Unfortunately, scrolling is a common operation in mobile and the user expects a smooth, 60 fps experience like the OS provides.

I managed to improve performance implementing a crude rectangle test loop which hides any out of screen elements in a LateUpdate call. SetActive is surprisingly expensive, but calling it only on the few elements which come in or out of screen is fast enough to make the screen usable.

 

Is your text set to best fit by any chance?

 

I just wanted to come back here and report that yes!! Seperate canvases can be used for culling UI elements.

Place each major UI view in a seperate canvas. Set your UI camera to only draw UI layer. Set the layers of your UI canvases to Default. Now no UI elements will issue a draw call but all of them are set to Active and visibel in scene view.

When a UI view is needed switch the canvas layer to UI and it will start drawing on the screen without any performance impact caused by SetActive(true) happening simultaneously on 200+ ui elements.

 

Would interesting to hear what Unity devs think about this. Wonder if this behavior might change when they get to performance optimizations.

 

Same big problems here ( 4.6.1 )
With about 150 buttons and about 300 text, when scrolling, ScrollRect brings the App to a almost a standstill.
The impression is that the canvas is probably rebuilt at each frame, hence the 2 FPS we experience.

EDIT:
A temporary solution is to disable: LayoutGroup, LayoutElement and ContentSizeFitter everywhere after the page has been formatted.
So it is confirmed that uGUI rebuilds the canvas unnecessarily every frame during scrolling.

 

You should report a bug with your scene

 

@gavi, did you submit a bug report?

 

@gavi thanks for the tip on disabling components. After going multicanvas (+ no pixel perfect on nested one), and disable all UI layouting related components after rect content is layouted (canvas size fitter, layout groups, layout element) we were able to improve performance of one of our complex lists from ~2fps to ~30fps on lumia 630. Hope this helps.

 

Hi guys, we had similar issues and this is why i bumped to this thread. Our experience was a bit different: mobile scenario with 5-6 elements on a single canvas. We have three buttons and three text controls there, and we actually had two problems: a) low fps and b) slow to respond (buttons).

What we did was to disable the events on the buttons, and that did the trick.

The way the event system works (choosing a class, and then a function on this class) lead me to believe that some good old fashioned reflection is being used to achieve this kind of functionality (what else could it be?). It is a well known fact that reflection is very powerful but comes with a performance penalty.

The way we solved this is that we actually removed the events from the buttons and use the Touch system instead. We divided the screen area dynamically (as to scale with the buttons) and this solved the problem straight away.

Please note that this worked in our case - we did not have to many elements for the canvas to draw, and the design was such that it was easy to accommodate.

Finally, i can't be 100% sure that reflection was to blame, but the hypothesis and the evidence were congruent to our situation.

I Hope that this was of some use.

 

I am seeing absolutely atrocious performance on iOS (specifically on an iphone4, running os7).

With 5 images, each with 3 pieces of UI.Text on them, I get 22fps on the device. There is also a little gradient background.

When I build the same scene using just sprites and the old textmesh, I get 60fps. What is happening with my other 32fps? It seems like the majority of the framerate drop is coming from that gradient drop being behind the elements, but the fact that I am not seeing a drop at all in the non UI version is frustrating. Is this a result of bad batching with overlayed elements? is there a way that I can turn off the batching?

I am seeing much much worse performance in my actual project, it is hovering between 5-9 fps.

 

Did you submit a bug report?

 

yup, sure did hoping to see this fixed up soon, because I am working towards a deadline. Hope I don't have to reimplement everything with nGUI, since the whole game is implemented using UnityUI. (bug number 675716)

 

well, I managed to reduce my problem to two issues, one of which I kinda understand, and the second of which I don't.
The first is that the default shader for ui elements is too much to be handled by iphone4. I removed features until it ran again (took out the stencil check, the discard function, and some other stuff).

The second issue is that I had a background made up of scrolling elements of the game. Even with the shader sped up, it was still giving terrible performance, there is something happening inside ontransformchanged that was chewing up 33ms of CPU time just by itself. I guess there is some magic that happens with rect transforms that is slow?

I just replaced that scrolling background with a sprite based thing that uses the standard transforms, and it is much faster, but can't live inside of the ui

 

Did you try to create a canvas just for the background?

 

yeah, I had two separate canvases, one for the scrolling bg, and one for the fg.

 

I was having performance issues in my test scenes with the new UI on iPhone 4 (Using Unity 5.0.0f4). However, it seems that it was all due to the default material. It took me quite a while to figure out the cause. I was suspecting the layout components etc. on my way to this conclusion. Thanks jonbro5556 for the mention on the default material. I have now tested all my scenarios and combinations, and this was the issue with my setup.

This is definitely a bit of an issue, because the cause for the performance wreck can take a while to figure out with the process of constantly building and deploying to the platform, getting more and more frustrated on the way. A quick and dirty solution would be simply to issue a message box warning on the editor if you are deploying to mobile and using those materials on the UI.

I guess jonbro in your bug report, you pointed out this default material thingy?

 

Scrolling text in a ScrollRect seems to drop the framerate to 24-30 on iPhone 4 (I was using 60 as my upper limit, to test the performance). Perhaps this is normal, since text is a fairly complex thing to render? Removing layouting did not seem to affect framerate. Also, 30 is enough for the iPhone anyways, due to battery consumption. However, I myself do see a tiny bit of jerking, not too bad perhaps, as the framerate fluxuates downwards a little.

In any case, a steady 30 would be the best, of course (when the max is set to the default 30, I mean).

 

I am not sure that I did actually. It is probably worth filing another report so they know that we are still having performance issues?

 

Ok, I'll do that, thanks. I'll tell about the def mat and text issues on iPhone 4. There could still be more issues with mobile here and there, however. Let's hope not too many. I am just getting started with my UI setup for iOS, and testing the features that I will need for building it. I have only noticed these issues so far. Text slowdown on scroll could be understandable, maybe, but I am wondering if it could be improved with some optimizations.

 

hey, someone asked me to share my shader file, so here it is. Basically it just turns the stencil check off. Also, a note, this didn't fully solve the issue for me, I ended up having to reimplement all the game stuff that I was doing in the unity UI with my own mesh rendering routines, even the sprite batching was slowing up everything too much when I switched it over to unity sprite system.

I dunno, it seems to me like performance of the new ui has a ways to go.

 

I simply use the mobile shaders provided, they seem to do the trick. For some reason, at least in my setup, only the 'Mobile/Particles' type shaders seem to work, for some reason.

Also, as a curious "detail", the Source Image is not taken into account at all in any Image or RawImage component -- I need to set the texture in the material in order to get anything showing on the screen, which means I have to use separate materials for each individual case! What a pain!

I should post a bug about these issues as well, actually

 

My problem here is that I have made a collection of many icons in a scroller. Most of the icons are scrolled off-screen most of the time. I assumed that they would not be drawn if they were masked by the scroller.

Turning them on and off using SetActive is VERY expensive. I cannot change their render layer as they are drawn regardless of render layer. I have resorted to changing the parent of the transform of PARTS of the object but I need to leave something behind so that the scroller retains its shape and size.

I think the new canvas object needs to do some frustum culling type calculations so that assets that are not in view are not drawn. I think this has been missed at the moment.

 

What about setting enabled = false on the image components?

A shader could perhaps do the trick for culling. This is an extremely uneducated guess on the topic, however.

 

Are there any plans to fix the performance of the new UI in future versions?

Tested today: still can't use WorldSpace canvas at all - the performance is appallingly bad. It's as if the implementer assumed you'd only ever have a single button in your world.

e.g. in a small village scene, 120 FPS normal, adding a WorldSpace canvas to each door (> 90% of which are off screen, and at least 70% of which are frustum culled, let alone occluded) with a single 128x128 sprite ... FPS drops to 70.

It's laughably bad, and makes the whole "world space UI" unusable .

 

Guys I didnt read the thread well but I want to state that
5.1.p1 was showing same scroll area with lots of UI elements inside 150 draw call
I downloaded 5.1p4, same UI it shows 10 draw call

Some bugs may occur. Try to use latest versions.
Also my experiences with draw calls
1-Use sprite packer for your sprites to reduce draw calls
2- Pay attention UI elements are not overlapped with eachother.
3- Develop a system which disables panels,UI elements etc wich are outside of viewing frustum.

 

Thanks for the update.

 

Bumping this thread. We are getting slow responses to touches with the new UI. Would be interested in some good practices when using Unity UI.

Once we get into performance analysis will be happy to share the information to identify bottlenecks.

 

I found this release note for 5.1.2f1, after reading your post about the patch releases:

• (689600) - UI: Number of batches created for UI scene back down to 5.0 number.

 

Ok, guys.
I found the way, how we can fix perfomance of the new UI system. I just use the material "Sprites-Default" in almost all UI elements. On Android with default UI material I get about 33fps, with Sprites-Default about 60fps.
Hope it helps.

P.S. Sorry for my ENGRISH.

 

Do you change the "Image" component material?
Is there a way to change all the default Image material somewhere in the editor or should I do it myself (by script)?

Code (CSharp):

1. using UnityEngine;
2. using UnityEditor;
3. using UnityEngine.UI;
4.  
5. public class SetImagesMaterialWizard : ScriptableWizard
6. {
7.    public Material material;
8.  
9.    [MenuItem("Tools/Set Images Material")]
10.    static void CreateWizard()
11.    {
12.      ScriptableWizard.DisplayWizard<SetImagesMaterialWizard>(
13.         "Set Images Material", "Quit", "Apply");
14.    }
15.  
16.    void OnWizardCreate()
17.    {
18.    }
19.  
20.  
21.    void OnWizardOtherButton()
22.    {
23.      Image [] images = GameObject.FindObjectsOfType<Image>();
24.      foreach (Image image in images)
25.      {
26.        image.material = material;
27.      }
28.    }
29. }

doesn't seem to work
errors : "Material Sprites-Default doesn't have stencil properties"

 

You are tried it in version 5.1.x or 5.2.x?
I have this solution only works for 5.1.x, but not for the 5.2.x ...

 

We here use 5.2.x and all our games have issues with scroll rect slowing down our games. Everything else seems to work fine.

 

Any news about this issue? Did unity developers notice about this?