Hey everyone, apologies for the lack of GearBlocks updates recently. I’ve been working on porting all of the menus and other UI over to the new UI system that was introduced in Unity 4.6. I wanted to get the port out the way sooner rather than later, before I add any new features that require UI changes or additions. Unfortunately it’s taken me much longer than expected, I’m getting there, but I probably still have one more week left to go on it.
Previously I was using the old immediate mode UI system, which has its well known limitations that I won’t go into here, I’m guessing it will eventually be phased out in future releases of Unity. The new system is for sure a lot more powerful and flexible, and of course you get to properly lay out your UIs in a WYSIWYG fashion.
Issues with the new UI system
Unfortunately once I got into it, I found there were some downsides to moving to the new system. For instance, some of the features of the immediate mode UI I was using (e.g. selection grids) do not come “built in” and I had to write additional code to replicate them. Also, some bits of the UI that I populate at run-time (e.g. the parts list in the inventory screen) required significant rework to the code that does the populating (simply because of the totally different philosophies of the old vs. new UI system). The most troubling issue though was the performance of the new UI system, I discovered if you’re not careful you can easily add many ms. to your frame time, with spikes in the hundreds of ms!
UI performance problems
GearBlocks has many separate UI screens that the user can transition between. The “standard” way to implement this in the new UI system (at least from the tutorials I’ve seen) is to use an animation controller to blend each screen between an open and closed state, these states setting the screen’s CanvasGroup visibility and interactibility. However I found that the animation blend added a couple of ms. (from Animator.Update and Canvas.BuildBatch) during a transition. Even worse, despite all screens (apart from the currently active one) being invisible and non-interactible), they still all seemed to get processed and I found that this resulted in several ms. of overhead from the EventSystem update.
To get around the transition blend cost, I did away with animations for the in-game UI and just did the transitions directly from code (I kept using animations in the main menu though as the performance cost isn’t so critical there). For the second problem, I wanted to eliminate any cost for a non-active screen – it’s not really practical to go through and disable each and every UI behaviour, so I tried deactivating the screen’s root GameObject. Unfortunately, while this does eliminate the continuous frame-by-frame cost, it can result in huge performance spikes when activating / deactivating the GameObject (I found hundreds of ms. if you have a complex screen with ScrollRects), so it’s not a viable option.
Luckily I found another solution, which is to have a separate Canvas and GraphicRaycaster for each and every screen, then enable / disable these to transition between screens. This way you get the best of both worlds, no cost for inactive screens, and no cost to activate / deactivate them. I get the impression this is a common trick people use to get around this problem. It seems like there are a few performance tricks people are discovering (such as disabling Canvas “pixel perfect” when using ScrollRects).
Well, hopefully I’ll be done with the UI port soon, and then I can get back to adding new stuff to the game!