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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
