Hello! That’s been in the plans for a while but it hasn’t happened yet unfortunately. The team has worked on a many performance improvements in UITK’s text, such as jobification and an enhanced caching system. However, adding a method to set text with zero allocation is definitely something that needs to be done.
Also I don’t know what the internal plans are here, but it would be really great if that method when added has an overload that takes in a ReadOnlySpan<char>.
I’m thinking of moving over to UI Toolkit for certain parts in my current project. However, my game is reliant on updating text, especially numbers (!), on multiple sources almost every frame. TMPro’s APIs make this very efficient and result in 0 GC allocs. If I were to use UI Toolkit instead, I would allocate tons of memory constantly. That can’t be good.
So, what are the chances the APIs, as mentioned in this thread, were to be implemented within like a year or so? I’m fine with these GC allocs during development, but I wouldn’t want them in my builds in the end. If the chances are low, then I won’t risk it.
We’re using UI Toolkit in our project, and this is definitely something we’re very much looking forward too. Any idea whether this will be released within the 6.x timeline?
I will join the comrades above, this is an extremely useful and necessary function. We are sincerely looking forward to its implementation, as we are trying to fully transfer the project to the UI Toolkit (now it has become more possible than ever).
@laila-chammaa One more ping on the above to ask if the plans are still in place, and whether you’d be able to share a (non binding) indication of whether we’re looking at seeing this in 6.x, 7.0, or further into the future? It’s really a necessary feature for dynamic runtime UI.
Also, if you’re able to share any details of the plans it could help a ton now. If ReadOnlySpan<char> is the way you’re headed, then it should be possible to write a custom element today which internally uses spans and simply .ToString() it into the .text attribute, safe in the knowledge that we’ll soon be able to pass the span directly. Being able to use an allocating version in development now knowing we can make simple, localised changes in the future to remove the allocation would be great, but I’d rather not guess whether I should use ReadOnlySpan<char> or FixedString or StringBuilder.