PoC: flexible height of list items

[hius07]

May be useful for bookmark list, or fulltext search results list.
In the example the height is limited by 4 lines.

But the main problem is the speed.
The above list of 260 bookmarks is built for less than 2 sec without flexible height, and for about 7 sec with it.
It is too long and I see no way to speed up: without flexible height we build TextBoxWidget items for one page only, and for flexible height we must build all TextBoxWidget items before displaying.

[Frenzie]

I suppose that on faster devices (or in other words, not ereaders) the performance impact might be acceptable but yeah, that's a lot.

[jonnyl2]

I really like the looks of it, FWIW. Bummer that the performance difference is that stark.

[Commodore64user]

So it is faster to render the whole book than to make that bookmark list, that's something. I already think "full search" takes a bit too long when you look up a popular word, with this it would take forever, but it looks so much nicer.

[hius07]

As usual, we can speed up by sacrificing the precision.

To build the felxible height list we need to know the height of each item.
Building real items with TextBoxWidget to get the exact height is too long.

I tried to calculate the estimated height for given available width:
number_of_chars_in_line = available_width / char_width
number_of_lines = total_number_of_chars / number_of_chars_in_line
item_height = number_of_lines * line_height

I took a width of "M" as char_width. It is a wide letter, so we need less lines for actual text (with narrow letters). But we do not use full available width in each line (unjustified), so we need more lines. Some kind of a balance.

It is really fast, no delay in building the long bookmark list.

One bad case is that we could give an item less height than it requires, and it will be truncated. For example, the max number of lines is set to 4, estimated calculation produces 3, we draw the item in 3 lines and it is truncated - it could be drawn in 4 lines without truncation.
Another bad case is that we give an item more height than it requires - there will be a blank bottom line.
I cannot reproduce these cases in the test book with 260 bookmarks, pretty well.

[poire-z]

number_of_lines = total_number_of_chars / number_of_chars_in_line

Dunno how you estimate the total_number_of_chars - but if you just use the string length, in languages with lots of diacritics or complex shaping (some hebrew, indic), the actual nb of "glyphs" (chars taking the ~ room of M) may be half the string length.
May be rendering it once at a fixed font size with TextWidget to get the actual full string length, or using some xtext.cpp existing methods (haven't looked what's available) may work better.

[hius07]

how you estimate the total_number_of_chars

#util.splitToChars(item.text)

[hius07]

Building 260 bookmarks measurement (sec):
splitToChars: 0.1656
TextWidget: 0.4778
TextBoxWidget: 5.2927

Half a second is acceptable I think.

[Commodore64user]

Another bad case is that we give an item more height than it requires - there will be a blank bottom line.

This is already the case (with current implementation), so not a big deal.

One bad case is that we could give an item less height than it requires, and it will be truncated.

Seems like a sacrifice I am willing to make it.