[Interest] Can a view somehow notify a model of which rows it is going to show on screen?

[Mark Gaiser]

On Tue, Apr 22, 2014 at 9:38 PM, Andre Somers <andre at familiesomers.nl> wrote:
> Mark Gaiser schreef op 20-4-2014 4:04:
>> Hi,
>>
>> the title says it all...
>>
>> I can't find any signals that expose this information in the model.
>> I would like to know this from the QML ListView component. What i can
>> do is tell the model where the current y position is in the models
>> content and the height of each row. That gives me enough information
>> to calculate which rows are visible, but i'm hoping there is "some"
>> way out there that i just haven't discovered yet.
>>
>> I'm asking because i have a big dataset and only want to sort the data
>> that is visible for the user (partial_sort along with nth_element will
>> do that).
> AFAIK, there are no facilities for that. The way to know what data is
> needed, is simply to respond to the data() calls in QAbstractItemModel.
> Only rows that are needed are (should be) fetched. But that information
> is not shared in advance.

I figured out a way to do it fairly accurate.
Each ListView has the the itemAt function [1]. That allows you to get
your index from any position in the _content_ area.

That alone isn't enough since you still need to figure out which part
of your content area is shown. That information is luckily available
(and is also used for creating a scrollbar). It's the contentY[2]
property.

Now, if you use itemAt with the contentY property we know the
beginning pixel of our view and itemAt neatly shows us which index
belongs on that position.
Next, we still need to know the last item in the view. To figure that
you we simply do:
yBottomPos = contentY + height (height is the height of your listview itself)

There we have it. All visible item indexes accurately known. :)
I think i just answered myself, hehehe

>
> Are you sure that this is your performance bottleneck though? To me, it
> sounds like premature optimization to worry about this and to try to
> optimize this.

You can see it both ways.

Usecase:
If you only look at small folders then this definitely is premature
optimizations since the "regular sorting" will do just fine there.
Bit if you look at insanely massive folders with 500.000 items. All
stuffed in one ListView (where you only see ~50 or so). Sorting that
by string in a natural way (using QCollator) is very slow. In my case
~6 seconds. I know that giving a ListView a task with that many items
is insane and in most cases you're probably better of splitting the
data in chunks. This however is a difficult thing to do with massive
folders so i'm optimizing for that case.
The assumption is that it's implementation will be fine for small
folders, but absolutely necessary for massive folders. I already have
it partly working, but it is very difficult to get it working right by
sorting (partial_sort actually) as little items as possible. That
requires a bit of complicated bookkeeping.

In reality this will unlikely be an issue - ever. The only place where
you can begin to see it's benefit is when browsing through "large"
folders like /usr/bin and /usr/lib on linux.

[1] http://qt-project.org/doc/qt-5/qml-qtquick-listview.html#indexAt-method
[2] http://qt-project.org/doc/qt-5/qml-qtquick-flickable.html#contentY-prop