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.

1 Like

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!!

1 Like

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, in 4.6.0 patch 1 we did a bunch of performance optimisation. I would start by grabbing that patch release and taking a look (it should come out today or tomorrow here: Download Archive). If you still experience issues after using this release then please log a bug with repro steps and a project. We are very happy to look at, optimise, and fix, performance issues.

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.

1 Like

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.

1 Like

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.