Discussion: expectations for large container performance

[cceckman]

Splitting off this discussion from #84, and calling back to #14 (so ping @yml if you're interested.)

By "containers", I mean any widget that can own an arbitrarily large amount of data, so:

• Label, StatusBar, containing large strings
• Grid, Table, Box, containing many Widgets
• ScrollArea, containing an arbitrarily large buffer to be rendered and then masked
• ?

I did some reading on https://www.finseth.com/craft/ when I implemented the RuneBuffer and I think it would be wise to have a better separation of the text view and text content. Right now we draw everything and then mask it away.
Also, separating the view and the content would make it feasable to load large files and maybe even remotely(?).

• @marcusolsson in comment on Reset Label's cached size hint on Resize #84

I think an underlying question here is which part of "display things efficiently" is the responsibility of the view (i.e.tui) versus the controller (application logic.)

At the moment, it's necessarily the controller- Box doesn't really support overflow (displaying more elements than it can display, hence TailBox) or scrolling across that overflow.

It doesn't have to be that way- we could work on making containers scale to large contents: have each container Widget track what portion of it is displayed, and only render that subset. I think this is a nontrivial problem- in particular, ScrollArea is by design unbounded.

An alternative is putting some guidelines on usage of tui:

Don't create arbitrarily large Widgets, e.g. a Label that includes all of the data in a file. tui may have to scan the entire file to properly render it; this may lead to poor performance.

• Don't keep an arbitrarily large number of Widgets live, e.g. a Label for every line in an arbitrarily large file, or a Label for every chat message. tui may have to render every one of these to render the display; this may lead to poor performance.

If you find yourself wanting to do one of these, write some application-level code that keeps the number and size of Widgets reasonable. Consider embedding Widgets and responding to Resize calls to fill with the appropriate number of Widgets.

It's been a few years since I've done interface with a UI layer- how do other UI frameworks handle this? Is there similar behavior / guidance / best practices from other toolkits? (I recall some weird and fun behavior in Android that came from a ListView re-using its ListItem widgets on scrolling- which does indicate the UI layer was trying to keep the number of widgets bounded.)