On Tue, Apr 22, 2014 at 9:38 PM, Andre Somers <an...@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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
