On Mon, Apr 18, 2016 at 1:25 PM, Omer Akram <[email protected]> wrote:
> > > On Mon, Apr 18, 2016 at 4:43 PM, Alberto Mardegan < > [email protected]> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~ubuntu-phone >> More help : https://help.launchpad.net/ListHelp >> > > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
