On Thu, Jan 10, 2013 at 7:24 PM, Aaron J. Seigo <ase...@kde.org> wrote: > On Thursday, January 10, 2013 16:49:15 you wrote: >> On Thu, Jan 10, 2013 at 3:53 PM, Aaron J. Seigo <ase...@kde.org> wrote: >> > * 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. >> >> Would a 300ms timer be acceptable in user experience? So if there are >> new thumbnails available, batch them and update the model only once >> every 300ms. Or is 300ms too much? > > probably too much (and probably more than is needed for the rate of file > listing). but once you have that delay in there it is easy to test it, right? > 100, 200, 300 .. it will really come down to average listing performance. if > items come in clumps, then the update might only need to be really small (50ms > or even less) to drop the # of updates by orders of magnitude.
Guess i just have to experiment there. > >> Interesting! My DirModel is coming directly from plasma-mobile [1] >> which is not doing the threading you describe. > > yes, i noticed :) unfortunately for you, that class was thrown together very > quickly for the limited needs of listing directories on a mobile device. file > counts tend to be rather low there, and file system browsing is not as core a > function as it is on the desktop. so for Plasma Active, this was acceptable > performance. for the desktop .. not even close :) Well, the class didn't have _that_ much extra stuff on top of KDirModel and i added even more so mine is quite different at the moment. Though not threaded. > >> Is there another >> dirmodel fork somewhere that does that? Link please :) > > well, what we ought to do is do a threaded version and then put it somewhere > we can all share it properly :) i'll discuss with Marco what he thinks and > come back with a proposal. you make it sound like it's closed source..? no link to some exotic highly experimental git branch? > >> You just verified the need for KDirModel, KDirLister and KFileItem to >> be optmized for scalibility :-) > > yep. > >> How much work would it be to let KDirModel run in it's separate >> thread? I'm guessing the public KDirModel would internally be nothing >> more then a signal/slot mechanism to a KDirModelPrivate class which is >> sent to it's own thread? Or would you say that sending KDirModel to >> it's own thread it too risky and should be done by the developer using >> KDirModel (like dolphin and my app) rather then internally in the >> private API? > > for scalable models in Plasma Active, we've been putting the threading in the > model itself exactly as you described (threaded signal/slot communication > between the public API model and members in its private class) since doing > this in each application is error prone. once it is done properly in the > model, it then works everywhere. > > so +1 from me for making KDirModel do its business in an encapsulated thread. I guess that is the way forward then. But i do wonder, if the KDirModel API stays the same but the internals change completely, is that KF5 material or can it go in 4.xx as well? > > -- > Aaron J. Seigo (remember to press "reply to all" ^_-) _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
