ubuntu-phone team mailing list archive

[Andrea Bernabei <andrea.bernabei@xxxxxxxxxxxxx>]

On Mon, Apr 18, 2016 at 1:25 PM, Omer Akram <omer.akram@xxxxxxxxxxxxx>
wrote:

>
>
> On Mon, Apr 18, 2016 at 4:43 PM, Alberto Mardegan <
> alberto.mardegan@xxxxxxxxxxxxx> wrote:
>
>> On 18/04/2016 13:57, Omer Akram wrote:
>> > While working on a pet project[1] for the Phone, an issue that I faced
>> > was stuttering scrolling in listviews. QML tips page[2] suggested to use
>> > Flickable+Column+Repeater combination to have smooth scrolling, that
>> > worked and is currently what I have implemented in my app but I always
>> > thought that was not the perfect solution.
>> >
>> > With some knowledge of how Android ListView works and its mechanism of
>> > recycling ListView items, I wrote a hack[3] to achieve something similar
>> > in QML.
>> [...]
>>
>> You are trying to reinvent the QML ListView :-)
>> The QML ListView recycles the delegates, and this behaviour is partially
>> configurable via the cacheBuffer property:
>>
>>   http://doc.qt.io/qt-5/qml-qtquick-listview.html#cacheBuffer-prop
>
>
> My initial implementation was indeed using ListView and with a
> higher(random) cacheBuffer, it was smooth but I had that itch of
> experimenting and producing an optimized version of ListView. Plus I have
> seen quite a few apps in the store have scrolling issues.
>

The low framerate while scrolling apps which are currently on the store is
usually due to those apps using the old ListItems module, though :) (or the
fact that the delegates have too much logic)

That is now replaced by ListItem+SlotsLayout/ListItemLayout, but most of
the apps have not been ported over yet.

How much difference is there between old and new components?
Here are some numbers from the "tst_performance" benchmark used in the SDK
UI Toolkit, running on my laptop (i5 430 CPU and no SSD, the benchmark only
uses 1 thread, fwiw)

- OLD ListItems.Empty component (NO CONTENT, empty!) --> about 0.9msecs
VS
- NEW ListItem (empty) ---> about 0.08msecs, the new ListItem is 10x
cheaper to instantiate! and it also handles swiping actions!
VS
- NEW ListItem + ListItemLayout + 3 labels + 3 Items --->  about 0.5msecs

so, a "modern" delegate with 3 text labels and 3 (empty, in this benchmark)
Items is still 2x cheaper to instantiate than the old EMPTY list items!
That's a massive difference!

Hence my point: it really depends what components those apps are using :)
(and then, of course, it depends on much logic those delegates hold)

HTH,
Andrea



>>
>> Now, this means that when scrolling a listview, occasionally the
>> delegates need to be either created (the first time they are used) or
>> reused (which causes a reassignment of their properties based on the
>> model data).
>> Both these operations can be expensive, that's why someone gave the tip
>> of using a Column+Repeater when the number of delegates is low and
>> doesn't change, so that the whole list is created only once and
>> scrolling will be smooth.
>>
>
> Well, I think re-using already created elements and updating their
> properties is potentially much less resource hungry than creating a new
> element, though I don't have stats to prove that but my experimental
> ListView scrolls smooth, as I would expect it to.
>
>
>>
>> If now you found that this tip doesn't work well for you (typically
>> because of high memory consumption if the model has many items), it
>> means that you should go back to using a ListView. :-)
>>
>> Ciao,
>>   Alberto
>>
>> --
>> Mailing list: https://launchpad.net/~ubuntu-phone
>> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ubuntu-phone
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>
>