[Qt-interest] QAbstractListModel Scrolling Performance Issue

[Kaleb Pederson]

On Wed, Dec 3, 2008 at 9:59 AM, Stephan Rose <kermos at somrek.net> wrote:
>>When you scroll any of the list views, and I believe this also holds
>>true for the tree views, a paint request is made (to the delegate
>>responsible for drawing) for *EVERY* single row that you attempt to
>>scroll past.  Thus, it doesn't matter how fast you attempt to scroll
>>or what you actually end up viewing... it will try to draw everything!
>> This also means it has to request data for every single row and
>>visible column.
>
> Don't think it's a paint issue because the model becomes fast once I've scrolled all the way to the opposite end at least once. If it was a paint issue, that wouldn't matter.

I wasn't actually referring to it being a painting issue.  I was
looking at it as more of an optimization problem when the data is not
prefetched.  Without the proxy model, but using paging for fetching,
it could be beneficial to separate the scrollbar from the view so that
you don't have to fetch all of the data.  You could then just page in
the data as it's needed, and without the scrollbar lag that's present.
 When dealing with data that's larger than will fit in memory, this
should help a lot.

>>Since it tries to draw everything, until *ALL* your data has been
>>fully fetched it's not going to be ready to display and, therefore,
>>will be slow.  It also explains why it's fast once you've viewed all
>>the records.  The data has been fetched and is available within the
>>model/view.
>
> At the time of my testing however, I've ensured that for a fact all data was already fetched and put into the model's data storage used by the ::data() call. So the problem isn't in the fetching of the data from the SQL Server. The model doesn't even know the SQL Server exists.

I had missed that in your original post.  That, as well as your
recently reported findings, are interesting.

--Kaleb