Support optimized list rendering about brick HOT 10 CLOSED

While thinking about this I went ahead and made a small improvement to the list API in d7bf9e1 which moved the list element drawing function from being in the list state itself to being a parameter to renderList, thus further separating the presentation and state concerns.

from brick.

I also changed lists to use Vector e instead of [e] in 14d2147 since many vector operations are O(1) while their list counterparts are O(n).

from brick.

I've pushed a commit (693abbb) to address this. The only user-facing change is that renderList now takes an item height (in rows) and all item widgets returned by the item drawing function must match that height (or else). It's in the feature/long-lists branch. Give that a try.

from brick.

FYI: I tested this solution with lists of 100,000 elements and saw no discernible performance difference between those and lists with ten elements. The reason is because the vector slice operation that obtains the sub-list is O(1).

from brick.

Thank you! Sounds great. (Of course, my items are variable height; this will be strong incentive to change that).

from brick.

Is that something your application needs? There might be other strategies, since you could always implement a custom widget and sidestep the List entirely. It would just be more work. :) But knowing that your elements all have the same height might have other benefits; I don't know.

from brick.

Currently when Ledger (and hledger's) register report contains multi-currency balances, each currency is shown on its own line.

In hledger's multicolumn balance reports, because this disrupted the tabular layout I changed this to show such balances on one line, comma separated. I plan do the same thing here.

from brick.

I confirm your latest List renders without the slowdown here too.

However I think str is no longer right-padding to the full terminal width. Eg with a box enclosing the list, each | of the box's right border is rendered immediately following the list element instead of at the terminal edge.

from brick.

If you can reproduce using a minimal demo program and file an issue, I would be happy to take a look!

from brick.

I'm going to mull over the change for this ticket and decide wether to merge to master; I need to decide whether giving up mixed-height list items is problematic.

from brick.