KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions

[Aaron J. Seigo]

On Thursday, January 10, 2013 14:12:30 you wrote:
> part very rapidly. No issue thus far. But when i start scrolling
> _while_ the data is dripping in it's ... not very responsive.

after a quick look: 

the DirModel is doing all the data retrieval in the main thread as well as 
instantly on demand (no batching, e.g.). this means:

* every allocation of a FileItem and all the work to populate it takes cycles 
away from the UI thread at the same time as the list is trying to scroll
* KFileItems are created *and* populated regardless of whether they will be 
used or not, which means during scrolling things will get slower the more you 
scroll. they are also fully populated on creation.

neither of these things is good. (and some of these issues have already been 
touched on in this thread)

this probably requires changes to KDirModel such as:

* put data processing into a thread; whether that means putting the whole of 
KDirModel into a worker thread or just having a thread pool for processing new 
KDirModelNodes / KFileItems .. others more familiar with the code would be 
able to answer that far better than i can right now :) but there should be 
near-zero time spent in the GUI thread for actually getting the file 
information

* KFileItem needs to support lazy loading to avoid unecessary work when the 
information is not actually requested. there is even a TODO about this in 
KFileItemPrivate::init() in the 4.10 branch :)

* methods like KDirModelPrivate::_k_slotNewItems need be faster and/or have 
their work moved into a thread. the number of times 
beginInsertRows/endInsertRows is called should also be minimized as that will 
innevitably create pauses in the GUI thread while it reacts to this

perhaps some of this is already done or being done in the frameworks branch 
(haven't looked yet; apologies in advance for that)

as to the DirModel class:

* the image cache is done in the main thread. that means updating a database 
and writing to disk in the UI thread .. when the goal is 60fps or better, this 
is likely going to be too slow.

* KIO::PreviewJobs are also in the main GUI thread. could be another cause for 
GUI latency.

* DirModel::rebuildUrlToIndex is O(n) and called whenever there are new items

* DirModel::updatePreview calls setData for each preview that it gets back. 
that causes dataChanged to be emitted. again, for each index. this needs to be 
batched up and/or DirModel should override data() itself to return 
Qt::DecorationRole when it has a preview.

btw, DirModel::itemForIndex looks like it is leaking memory.

so it seems DirModel is need of a scalibility refactor/rewrite, and KDirModel 
needs to be made read for use with threads in some fashion as well have its 
base performance improved with more lazy loading and batching of requests.

(this feels earily similar to the model rewrites Marco ended up doing for 
Plasma Active ... threads and batching, threads and batching. the UI thread 
must not be disturbed! :)

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130110/3a9a2593/attachment.sig>