I'm evaluating NoesisGUI for a game where we currently use NGUI, and I have a couple questions about scaling.

Suppose you have a scrollable list box with 10,000 or more rows in a table/grid with 3-4 columns of data. With our current UI(NGUI), this was obscenely expensive, as the UI system still builds the draw calls for that entire thing, even though you only see maybe 10 rows at a time. What we did in that case was make a custom UI that basically fakes the list size such that we only instantiate the elements that are within the viewable scroll area.

Are there any mechanisms in place in Noesis for doing similar optimizations to the UI so that a data set can't become so large as to kill the performance of the UI?

Thanks

Noesis supports "virtualization" for ListView/ListBox as in WPF that should take care your concern.

I was having trouble when showing ~100k rows before, but the Noesis team has already fixed it.

Ref: viewtopic.php?f=3&t=1090&p=6268&hilit=l ... tion#p6215

Excellent, thanks

Even without virtualization, we never draw things that are not visible. But yes, virtualization allow us to have in memory only a small subset of elements in the visual tree getting huge memory savings.

How does noesis generate the geometry to draw in a scrollable view for example? In NGUI, it involves laying out all those elements and generating a giant mesh buffer of all that geometry, even though only some small slice of it would ever be seen at a given time.

Presumably you aren't batching controls geometry in a similar way if you have the ability to very selectively draw the UI elements on a giant list like that to only do the work for what is seen.

This is totally different in Noesis. Our algorithm is extremely optimized for dynamic content, we batch and upload the needed geometry per frame.