KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions

Mark markg85 at gmail.com
Thu Jan 10 13:12:30 UTC 2013


On Thu, Jan 10, 2013 at 12:20 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Thursday, January 10, 2013 11:30:35 Mark wrote:
>> very rapidly, the actual view is still barely usable as long as files
>> are dripping in. This is the same in QML (ListView) as in QWidgets
>> The issue here is that the view - even though it's not
>> showing the items - is doing all the calculations for every item
>> added
>
> if so, then the QML is being done "wrong" in some way. the default views in
> QML (along with some we've written ourselves) only creates delegates for items
> that are shown along with +/-N pages for caching (so when you scroll you don't
> see things updating; the updates are happening N pages further down the
> scrolling)
>
> under no circumstances should the entire set of icons be laid out at any time.
> memory usage and CPU usage simply prohibits this, as you noted :)
>
> QML makes it really simple to just lay out what is needed (shown +/- some
> scroll-ahead pages); this in turn makes it easier to write the model so it is
> lazy loading: only load the essentials (even progressively; QML views handle
> this just fine) and then when requested load details.
>
> because QML binds data to properties, the async nature of this does not cause
> further complexity in your code: it all happens in the QML runtime. a new
> delegate is made for a given index (automatically based on scrol position and
> view size), it binds to the data for that index, the model then knows
> something has requested that data and goes to fetch it (whenever/however it
> feels :) and when it updates that data then the delegate also automatically is
> updated .. all without dealing with paint events and other annoyances of views
> with delegates written in the imperative style.
>
> this allows huge (even "infinite"!) size models to be written that feed views
> that are performant even on mobile devices ... with very little effort.
>
> in the case of dolphin, i can imagine a goal that could lead to over-
> calculating: wanting even spacing between all icons, which in turn means
> knowing how much space each and every icon will require (thumbnail? how much
> text? etc.) if that is the case currently, i would suggest dropping this goal
> and only change the spacing dimension when new icons are shown that require
> it. (again, easy enough with QML.)
>
> also, the model itself can process some statistics (e.g. longest name) as it
> loads. this can be put into a Q_PROPERTY that the QML can then access. with
> C++/QWidget, the annoyance with this approach is then you need to reference
> the C++ object with the exact type and you end up welding models and views
> together and .. with QML all the properties are dynamic. you can test for
> their existence and use them if they are there ... and this is also rather
> efficiently implemented.
>
> all of this is a very long-winded way of saying:
>
>         if you do QML correctly and write the model accordingly,
>         you should be able to have a stupidly fast view.
>         (at least from the user's perspective :)
>
> i know because i've seen QML views on models with millions of entries
> scrolling insanely smoothly with complex and beautiful delegates. i've also
> helped write a couple. including doing it "wrong" a few times while learning
> :)
>
> --
> Aaron J. Seigo
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>

Hi Aaron,

I will explain my model -> qml listview approach a little. This is
100% off topic though.

I'm loading my massive file list (1 million) into a KDirModel subclass [1].
That class is then assigned to QML [2].
Where it's being used [3].

Now when i'm opening a massive folder [4] i do see my data in the qml
part very rapidly. No issue thus far. But when i start scrolling
_while_ the data is dripping in it's ... not very responsive. It
works, no doubt about it but isn't fluid. As soon as the data finished
loading (aka, no more data is added to the model) the list is very
responsive and can easily scroll through millions of items.

Am i doing something wrong?

[1] http://gitorious.org/porpoise/master/blobs/master/dirmodel.h
[2] http://gitorious.org/porpoise/master/blobs/master/main.cpp#line26
[3] http://gitorious.org/porpoise/master/blobs/master/qml/Porpoise/ViewContainer.qml#line27
[4] http://gitorious.org/porpoise/master/blobs/master/qml/Porpoise/main.qml#line24


More information about the Kde-frameworks-devel mailing list