Feedback UI Toolkit Rant

Switching to RefreshItems was a significant improvement. Thank you @martinpa_unity

However, I'm still seeing a hit to FPS when calling RefreshItems. Enough to still see a stutter in Play Mode. Also tried switching from DynamicHeight to FixedHeight to see if that would help. (Setting the height in code instead of USS made me feel dirty.) Didn't seem to make a difference.

After looking at the docs, I can only imagine I went with Rebuild because those docs didn't exist when I adopted ListView. (Early UI Toolkit adopter)

ListView is complex and it would be nice if Unity gave it another round of love. For instance, I need its selection capabilities but not its scrolling capabilities. Feels like supporting overflow: scroll would be ideal. Then have the scroll capabilities turn on and off depending on that USS property.

Somewhat similarly, FixedHeight versus DynamicHeight shouldn't be something the front-end code worries about at all. The underlying engine should sniff that from the USS.

Here's my example:

 

I am only displaying 2 items. What do you mean by "set to expand"?

FWIW, setting the height in the UXML would also feel dirty to me. Height is a style in the USS paradigm. Having the USS height do nothing is a semantic dumpster fire IMO. I'd suggest at least having the console issue a warning or something. Regarding the performance, I assume you mean "query the resolved height of each and every item.", which in my case would actually be trivial because I imagine I'll max out at like 1/2 dozen items.

 

Thanks for the response.

To circle to the OP, this should be easier. I suspect many are feeling this.

I am finding it impossible to update my super simple ListView without getting framerate drops. This is a basic UI element. I am by any reasonable measure, generally speaking, a UI development expert. (Not a Unity UI expert FWIW)

I am just changing the number of elements in the list and it is not performant at an unusable level.

My development story here is that I've already wasted too much time on it; now I have to create my own component.

This isn't the outcome that Unity wants for its developers. I've staked my livelihood on this platform; I beseech Unity to work to make this better soon.

Thanks again for hearing me out.

 

Thank you for your sharing your experience tony

as you mentioned in your first comment, this rant isn't centered around the list view for sure, but it's a very important part of the whole system for us, our app contains tens if not hundreds of list views, we are using third party libraries to substitute for recycler views implementation

I don't have anything more to add after your thoughtful discission with martinpa, I just want to agree with the general notion.

I have dealt with list views since the very early android development, I never had to figure out how to configure so many options just to make a scroll view with some dynamic objects and maybe some separators

 

Thank you all for this discussion.
I have been dipping into UIToolkit over the last few days.
Seeing how clearly that it’s current state is not quite yet an across the board improvement, but more an alternative (which is better in some respects - worse in others) I think it wise to stick with the frustrating beast that I know, rather than commit time to learning another frustrating beast.