Can someone explain to me why Unity keeps claiming that UI Toolkit is more optimized than older canvas.
I’ve tried running various tests using both the old canvas and the UI Toolkit canvas but strangely I notice that UI Toolkit makes the game performance even 10 times worse than the old canvas.
Test I ran was a simple animated text and a jumpy image.
The performance of the old canvas actually was better. I still don’t understand the reason for using UI Toolkit. I don’t understand why it’s not just better to improve the old one instead of creating something totally that in my opinion much more confusing, complicated, poorly structured, difficult to handle in Editor. Whoever created this UI Toolkit looks like a prinicipiant as a dev. UI Toolkit includes almost nothing and nothing at all. For example I created an improved version of canvas to permanently remove grid layout , scrollbar , vertical layout , horizontal etc… This proves that it’s easier to improve something that already exists instead of creating a new thing and implementing more problems to fix or add.
I tried playing a demo version of Gem Hunter Match created by Unity they use UI Toolkit and I had big drops in FPS. Here I had an idea to reimplement the old canvas to test and magically I got 42 more FPS talking about a mid range device. But Unity keeps saying that using UI Toolkit even on older devices is still better. This seems like a joke to me. Because trying the game on the old device it barely runs on 3/4 constant fps.
But the real question is why not keep optimizing something that already exists?
Unity however recommends using UI Toolkit and that’s what I can’t understand why. It gives me no impression and has almost nothing new. All these things could have been added directly to the old canvas.
The structure itself almost looks like the style of Unreal Engine completely confusing. It looks more complicated and more things to add. To give an example to add a single image you need 3 files rather than placing an image directly on the screen or adding it to the canvas.
I’m not the one that can claim knows the intricacy of both systems but I do like to speculate. Probably because the old system was running on the GPU and the new one can run on the CPU freeing resources. also providing a better support to different languages. also usability for people with various disabilities. better support for porting the UI to different languages on the fly depending of user device language.
sometimes is better to just start from scratch instead of modifying something that exist.
especially if this could break ALL the past projects that used the older system which are basically ALL the unity apps ever created.
The old UI system’s code is cretaceous and to improve it would require tossing it out and starting anew anyway. So that’s why we have UI Toolkit; they tossed out the old system and made a new one.
I prefer it over uGUI despite some of its shortcomings and odd choices. Unity’s advice is of course evaluate which one is the best choice for the needs of your project. In my current project, UI Toolkit wins hand over fist compared to uGUI.
When you have a transform that changes often those elements should be marked with UsageHints.DynamicTransform I’m curious if that changes the performance of your test?
I do actually agree with you that the old system is superior. It’s easy to use and flawlessly blends with game development process. However I think Unity is too deep into UI Elements now and will probably not be going back.
I think the advantage of UI toolkit is that it’s superior at scale. In a large game, with hundreds, maybe thousands of elements, it could be quite difficult to update every font asset on a TextMeshPro, or the highlight color of every button. In UI Toolkit this is quite trivial.
Another advantage is the data binding system, which is (almost) good. This eliminates an enormous amount of MonoBehaviour boiler plate code. You just drag and drop your data and away you go.
However I still find it way faster to build UI in the traditional system.
It is not correctly so. At this point they had to do it with all the other APIs. What does it mean that to optimize something that already exists they have to start again overcomplicate it even more? The same thing they did with Cinemachine nothing was so crucial to change to have the same thing but optimized. UI Toolkit is nothing more than old uGUI canvas but in the most complicated way.
How exactly is UI Toolkit better than the old UI? What’s so much new about it? The same things could be implemented correctly in the old one by getting a great result. We can put in the case as an example Nova UI and the same thing as old uGUI but optimized x10 times than UI Toolkit and it still remains a drag & drop. Why complicate so much something that will not be worth it. I keep seeing that people using the old UI because precisely they want to use it because they have no alternative.
That’s the actual nightmare. They always start to overcomplicate starting from something new that they can’t even make it optimized at all nor couldn’t finish it and they keep asking others to wait for news and update to make it production ready.
Even the smaller team like Nova did a god job the same I can’t tell about UI Toolkit. Instead of making something that they can’t finish in time why just not buying already pre-made asset that already exist if they won’t do anything and make it own.
I really do not understand who had this initiative of making this system but to me it seems more like a begginer dev.
And yes I do tried to use Dynamic Transform barelly get +5 FPS more. Still old uGUI have better results on old/mid range device.
you must be young or new to how software development works. I’m not saying this in a bad way.
You are correct that things keep getting more complicated release after release but that is a product of exiting developer always asking for more control and more functionality.
Every software is like this. first you have a button and a text field and people are happy for a while, then they ask for a slider, then what about this thing? and that other thing? we want that! And then they ask for a way to change all the buttons at once from a centralized location.
why are you not using the older systems anyway? just don’t use cinemachine if you just need a static camera. or the old UI, why bother with the new UI if you don’t need it?
That wasn’t my point of saying use this or this one because it has this functionallity. Cinemachine is more like an extension to the actual Camera it wasn’t renamed to CinemachineToolkit then you need to use CameraMachine to replace the old Camera. No they kept it but they added it as an extension which is not a bad thing at all. If UI Toolkit was just an extension to improve the old UI it will definitely be one of the amazing work that Unity made.
Your last point make no sense to me now. Saying “why bother with the new UI if you don’t need it?” Now the question is do we have others alternative?
Why not making something that would be used by every users a useful thing.
Let’s to be honest. This current engine doesn’t have any UI system. How can someone create a video game without UI?
That’s the crucial part for making games or others stuff and still after many decade of years we only get a UI Toolkit which lack of many many options nor they optimized at all.
Does UI Toolkit use Jobs? Does it have a burst compiler?
At the end I’m sure that only 10% will keep using it and the remain will still keep using the old one.
I’m not using both of them right now since I’m using Nova UI. It’s indeed overkill both of them completely. But on the second place I still keep old UI for me.
@spiney199@altepTest I believe none of you actually readed the message. Anyway I said
I don’t use none of them. Why should I? They both has very bad performance especially UI Toolkit. So none of them is an option to use for future projects.
That’s why I was asking why is this even a thing? I do believe that one day Unity abandon UI Toolkit like they always did with the rest of new things and if this happens that would be one of the greatest move from them.
we read everything, you complain about the new UI which you have all the rights in the world to not be happy about it. only your arguments make no sense for me. if you say is bad, that is ok, but you don’t want to understand that they can’t just update the old system because is too embedded in the engine and will break compatibility with past projects. They now want to replace the HDRP URP and the default rendering systems with a new one the unified rendering. They can’t use either of the old systems, they will create a new system. same thing like with the UI
If you’ve established a major difference in performance between the offerings, provide replication steps so others can actually tell what you’re talking about.
An incomplete list off the top of my head. UI Toolkit is better in terms of:
Styling
Restyle anything centrally in a consistent and portable manner.
Styling can make use of variables, meaning there’s a single point of definition.
Styling rules are very powerful, and will improve as Unity implements more constraints.
Being able to transition most parameters without needing to write code or have a Component declare that capability is awesome.
Layout
The layout engine is much better, it isn’t at all as common to need to stagger layout or force reloads to get things positioned consistently. UGUI fails consistently.
Events
You can intercept events, allowing you to take or modify control without hard-coding references or disabling elements.
You can simply have an element capture all events!
You can synthesize events!
You can easily add new behaviour to controls in a generic manner.
Iteration time
UXML and USS can be hot reloaded if your setup allows for it.
You can edit with an IDE, meaning you can perform simple text operations, instead of having to mess with prefabs and drag and drop.
There’s no prefabs or components to dirty. UGUI loves to churn and break things by itself during editing or by having a prefab just exist in the scene.
The data can simply be merged as text without some opaque process like YAMLMerge.
Better code
You can use constructors, properly use readonly, and easily enforce compound objects as references are already set via code.
The binding system gives a great place to unify implementations, simplifying code approaches.
Lifetime isn’t entangled in components and gameobjects. If you remove something, you don’t need to put it somewhere or destroy it.
You can actually build complete UIs via code (without templates), while possible in UGUI it’s a nightmare.
Familiarity, interoperability, and unification
Those coming from web technologies can already use knowledge from CSS and flexbox.
The data format allows plugins—like exporting from Figma—to be built fairly easily.
The Editor already uses UITK, and you can take implementations across the two.
Custom visuals
The Vector API is a game changer!
The downsides are everything they list and are iterating on already, missing feature parity (world-space UI, shader support, some text stuff, etc), and initialization performance.
I don’t love the whole of UITK and I’m still learning what works and what doesn’t, but the benefits over UGUI are so abundant and clear, especially looking to the future.
I might think the people won’t only have a visual style of UI. Speaking of usage it’s extremly painful more than the actual uGUI.
Just give you as an example you can’t just simply create a scroll view and add to it an image. You need to create a thousands of uxml files to get this workaround and then you need to create a new script to be able to get something similar to “Grid Layout” there’s a billions of workarounds just for what?
Is that a joke or something else?
I’m not gonna even speak about this crucial part of the game development. This is like on of the most important things to have in the game.
And In my case I’m using a lot of masks clip that UITK doesn’t have at all.
It’s incredible to me how Unity start to push something new that you can’t literally use in game development.
Speaking of performance. Till now many people complains about performance especially on mobile phones. They already have an issue with a singular scroll rect.
Also Unity claims that using UI Toolkit on even older devices like Samsung S3 or Samsung S6 still benifit from a solid 30 FPS which is also fake.
I have an older device that is far away better than Samsung S6 and I still barelly can’t get 5 FPS.
Scene is only contains UITK nothing else. So I still don’t see any huge improvements at all.
UITK is more like create your own custom UI if you need some functions instead of relying on Unity’s updates.
For example in order to have Grid Layout you need to create a custom script for that particular case.
UITK is around scripts and files.
Seems like if Photoshop create something similar to this like if I want to create a custom button including a texture I need to write a script for that.
No in Photoshop you still drag & drop directly into your Canvas. Just immagine having every UI program that require you to write a script in order to add a button into Canvas or Grid Layout lol.
For me UITK is great for those who want to lose their times on creating something from scratch because it’s obvious that Unity won’t never add anything like this.
Another question that I forgot to mention why the batches is so broken in UITK with unknown reason?
1 button with 1 text results in 5 batches? Is that a new feature?
Not sure what you’re having difficulty with. I don’t tend use the UI Builder personally (pure UXML) but it seems pretty straight forward. From scratch:
UITK
Open the UI Builder.
Add a Scroll View.
Set flex grow to 1 so it fills the screen.
Add a Visual Element
Drag it into the Scroll View.
Assign the texture to the element.
Assign an appropriate width and height.
Save (or preview it in the window).
Create a UI Document in the scene.
Assign the UXML you saved to the UI Document.
(ideally you’d do styling in a style sheet)
UGUI
Create a Scroll View
Navigate to the canvas by entering 2D mode and pressing F.
Anchor it to fill the screen (by holding alt and clicking the bottom right option in the Rect Transform).
Create an Image
Expand the hierarchy and drag it into the Scroll View’s Content container.
Assign the Texture to the Image (it must be a sprite, so go change that).
Change the pivot to the top left (0, 1).
Anchor it to the top left (by holding alt and clicking the top left option in the Rect Transform).
Assign an appropriate width and height.
Create a prefab
They’re both very comparable but UGUI’s steps involve intricate fiddling and domain-specific knowledge.
At the end UGUI has a prefab asset that’s hard to merge, awkward to style, and easy to accidentally modify/break/override.
And UITK gives you a text file that’s human-readable, mergable, can be modified and hot-reloaded during play-mode. It also already has a consistent layout running. With some extra steps on the UITK side you could style via a style sheet and gain the aforementioned benefits but for styling.
Here is where I’m getting really confused.
First of all on the old uGUI we use on any container that we want a GridLayout and assign their values for all the rest of the buttons or whatever it is.
For example if I create a scroll View in UITK I can add buttons to it that is already a container itself but if I want to use it as a grid I need to access to this container using uss but then even If I set
flex-direction: row;
flex-wrap: wrap;
It doesn’t allow me to specify column, row , space-between (from what I understand you can use Align and set Justify content to space-between) but it doesn’t give me the ability to modify it. What if I do not want to use auto space-between and instead I want to set value to somewhere 55px X and 55px Y. How would I access to that particular case?
How would I limit column to 5 elements and start again from the next column automatically? How would I add to this 5 elements a space between them? I know it could be done specifying the padding and margin directly on the Buttons but what If want to apply it directly from scroll view container for general usage instead of relying on buttons margin and padding?
Here’s a mini simple video to show something weird. I’m testing this using the same identical button with icons and texts. Yes it’s indeed has sprite atlas.
UI Toolkit testing here’s the video.
As you can see I have a scroll view centred in middle of the Canvas but for some reason when I press on play it jump immediately off the screen. In the UI Builder it showing it correctly same as preview.
The second one is a MultiColumnView which is correctly placed.
A lot of people may not agree with you, but I completely do. In my opinion, introducing UI Toolkit was one of Unity’s worst moves. I would have chosen Nova if the developer had kept updating it.
for now, I’m using the canvas in my current project and everything is fine.
Because I think they’re more like a fan base of UI Toolkit who loves using uxml / uss web style. I see that in many other forums they still defending UI Toolkit even when the people stuck on some issues that can’t be solved nor they suggest anything that may fix that. Which why all of this phantomatic dislikes(the same people across the other forums).
If you start to use UI Toolkit you need to be aware that in some step you will be locked.
In my case I’m not creating any game right now. I’m only testing UI Toolkit in many ways possible to understand if you can build a solid game using this UI System without stucking on a particular issue that only can be fixed by Unity.
Unity need to decide what type of engine they try to bring more like Web engine or Game engine. If both they need to have a solid solution for both of them and not only one.
Unfortunately that’s the reality when something great made by a small team remain unseen for years. Unity could definitely buy it and make it own. It’s indeed faster by like x10 times if not more than the actual UI we got today.
And still even if the developer stop supporting it. It still remains one of the fastest UI and with a simple usage. It does even have a world-space UI, shader support. lol
I still suggest you to keep old uGUI just to not waste your time. It’s indeed work fine because at least it was complete.
Probably because the old system was running on the GPU and the new one can run on the CPU freeing resources. also providing a better support to different languages. also usability for people with various disabilities. better support for porting the UI to different languages on the fly depending of user device language. 
