Unity UI What is the future of UGUI?

I just watched the Unite 2018 LA Keynote and once again was disappointed that there was no mention whatsoever of UGUI. All this talk of "performance by default" and the Job System + ECS is great but the truth is for many project UGUI is a huge performance bottleneck. Even things like the new SVG system which seems like a no brainer for UI work does not have support in UGUI. Looking at the roadmap I see nothing about UGUI whatsoever and if you look at the bitbucket repo no commits have been made since February for version 2017.3!

It would be great if Unity would be upfront about there future plans and the current status of UGUI. Will it get new features? Will it be optimized? will it be replaced by the new UIElements system?

 

Exactly the question I wanted to ask after watching the keynote and the list of unite sessions. There's no even UI experts at the "meet the expert" section...

 

I just came from the unity road map talk and still no mention of UGUI. When someone asked about it, they said that UGUI is only in bug fix mode and will eventually be replaced with the new UIElements. That's a long ways away, but still sad that UGUI is basically no longer in development.

 

@phil-Unity @benoitd_unity
Can you further comment on this issue?
Is uGUI in bug fix mode only from no now so no new features/performance improvements etc?
Is UIElements supposed to become new "default" UI system somewhere in the future?

 

So no uGUI isn't just in bug fix mode we've just been short staffed so some priority has been on bug fixes over features.

That being said we have work in progress as we speak. SVG is already supported in uGUI (SVG package has a SVGImage component that needs to be used instead), Tight mesh sprites are coming for 18.3, particle support is 75% of the way (no timeline for this atm but will be in the roadmap when we know more concrete times), Batching performance is on the list, UIElements has a new rendering pipeline that we are thinking of reusing or at least taking there performance ideas and implementing them within uGUI, and we are trying to find away around layout rebuilding performance issues and animation.

There is no concrete plan on if UIElements will full on replace uGUI, its been thought about but we know uGUI is a majour use case and will have support long after UIElements is able to support Runtime which is still a unknown length of time away.

 

Thanks for the update @phil-Unity, that's great to hear! Is being short staffed one of the reasons why the Unity UI Bitbucket hasn't been updated for a while? People have been wondering about that too (https://forum.unity.com/threads/is-ugui-no-longer-open-source.547052/).

 

Yes exactly the same issue. I do have someone working on it atm, but his computer just died so that put us back again . Hopefully really soon we'll have 17.4 18.1 and 18.2 uploaded (at this pace maybe even 18.3).

 

Awesome, thanks again @phil-Unity!

 

Thanks @phil-Unity I have hope for the future

 

I must admit UI (& text mesh pro) being short staffed is so surprising to me, on some games (and especially non-games) the UI is the most important part so I can not help being curious as to why Unity has not managed to fully staff this area of the dev team

 

Not going to get into politics of it all but yes i agree and its something I've been actively trying to solve.

 

From 2019.1 announcement:

UI Elements
This is a new retained-mode GUI system that enables developers to quickly create and edit UI layouts and styling. The new GUI system borrows concepts from the web’s CSS, jQuery, HTML DOM, and Events system to make it easier to create and optimize UI in Unity. It also provides improved performance and many new features, including stylesheets and dynamic/contextual event handling. We built the new system with performance and scalability in mind, so it has a conventional and comprehensive C# API that enables developers to build, modify, and interact with the UI. The familiar C# API, Events system, CSS and XML import formats make it easy to build user interfaces. UI Elements replaces IMGUI for extending and creating Editor UI, and will replace uGUI for creating runtime UI in future releases.

gg

 

Yes though that being said, we know that uGUI is used for most customers so we are still actively work on it and will be supporting it for the foreseeable future. I am also fighting the good fight for you guys and will ensure that when / if uGUI becomes "deprecated" that UIElements will at least do everything that uGUI does and hopefully more, with an amazing workflow.

By all means drop me a line and let me know what you think about UIElements and what it would need to be complete in your mind that you'd be willing to switch or why you'd be unwilling to switch if you had a choice. The more voices we have the better we can do in making sure we are doing whats best for you.

 

The current UI with nested prefabs is good, but not so complete.
No styling system or built in animation.
Limited control set.
These things can lead to a lot of time spent extending the UI code.

How will the new system do on those points?

 

Hi @phil-Unity, does UIElements will be implemented in DOTS? Last time I heard there's new DOTS UI System in the work.

 

UIElements will be the UI system that is compatible with DOTS. There is work still to be done but that work is already under way.

 

Our biggest issue with the UGUI is performance. The default layout components are so slow that we had to make our own (doing some intelligent caching, preventing containers from triggering their own refresh just because some value changed because of rounding errors, ...). By slow I mean literally 600ms+ per frame when using the default components instead of custom replacements for Horizontal/VerticalLayoutGroup/ContentSizeFitter.

Here's what I'd like to see:
- Prevent elements from triggering a layout rebuild when not really needed (tiny numeric differences, and also when the change itself is actually not relevant, like a box getting bigger but the child elements are not set to fill/stretch anyway)
- Provide a virtualized horizontal/vertical layout group (Not too hard to make yourself, but it should come built in)
- Stop layout calls from propagating up/down when it doesn't make sense - pretty hard to implement with the way the system is currently designed though. Like for example stop doing layout of all child elements when I drag a scrollbar, there's literally no reason (I know, the current system isn't smart enough to know what needs to be updated / what is affected, but that can and should be fixed!)

All of that is probably pretty hard to do (correctly) and not even worth the effort when considering that the upcoming UIElements tech will have its own, new, super optimized system to fix all of this (I hope? I think I've even seen a virtualized list kinda thing in the UIElements code already?)

Also, styling and (performant!!) animation would be nice.
But again, it'd probably best to wait for the runtime UIElements...

Ah, and a visual designer (just like UGUI) is definitely a must have, but I think that's something you guys are working on already as well.

I guess it makes most sense to just wait for runtime UIElements and rebuild all UI with that then, right?

On the other hand that will be a ton of work, and some things are so huge and tightly integrated with UGUI that it will be way too much work to reimplement everything using runtime UIElements (even if they'd be here and ready to go right now).

So if there's one thing I wish that would be worked on in UGUI it'd be performance!
Layout is ok for simple stuff, but a disaster for anything complicated. Rebuilding the canvases (graphics, building VBOs) is terrible as well.

 

It is certainly easy to destroy performance for layout/scrollview if you do not set it up in the best way (no pixel perfect, simple RectMask2D for masking). It should be easier to avoid such major performance issues.

Also the current layout system is obviously quite silly (huge world-space canvas), which I can only assume will be different in new system!

 

Well this seems like a bit of a curve ball. How does this (flutter inspired?) UIWidgets package factor in the the greater UI plans for Unity?
https://github.com/UnityTech/UIWidgets

 

When is the runtime version of UIElements going to be available?

 

I'm very worried about what could happen to both IMGUI and UnityEngine.UI. I know both have their flaw. But overall they do well in their respective field. And I understand that UIElements will solve and make possible needs for performance overall and specifically interoperability with DOTS.

But some of us, as entrepreneur, not hobbyists, are investing our time and our money, and are worried that our investment could be thrown in the bin because of the deprecation of a system that is just working well for us.
I'm not planning to use ECS, I know I don't have the need for it.
I'm not planning to use UIElements, I don't see any use-cases that would need it.
And, as I'm not hobbyist, I can't just give a new system a chance, and adopt it without any cost or risk.

To me, ECS is not a replacement of the Component based system, but a different concept / workflow for a different scale of project. And identically UIElements is not a replacement of IMGUI / UnityEngine.UI, but again a different concept / workflow for a different scale of needs.
(I could have said the same for Legacy Animation System vs Mecanim, sadly Mecanim has finally killed the Legacy Animation...).

I just hope Unity won't shift the concepts/tech that are foundations of our work, but find a way to make all of them coexist.

Regards.

 

(A bit off-topic but there is a talk at Unite Berlin 2018 that says Legacy Animation is not going anywhere and is an important optimization tool :

)