Review Request: Cache icon and accessibility in KFilePlacesItem

[Christoph Feck]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107030/#review20831
-----------------------------------------------------------

Ship it!


On a second look, I see no cluttering.

- Christoph Feck


On Oct. 24, 2012, 9:13 p.m., Dan Vrátil wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107030/
> -----------------------------------------------------------
> 
> (Updated Oct. 24, 2012, 9:13 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> -------
> 
> Similar to what Dolphin does in the "Places" pane, the open/save dialog should cache devices' icons, emblems and whether it's accessible, rather then querying Solid::Device all the time. Querying can cause Solid to ask udisksd to enumerate all devices (because with udisksd2 you can't ask for just a single device), which can take a lot of time (especially when slow devices like NFS shares or slow USB sticks are present).
> 
> Since this is a model item, the values are queried quite a lot, causing high CPU load from udiskds and the calling application blocks. Just try to quickly move mouse over Solid devices in the open/save dialog and what your CPU load).
> 
> Most visible result of this caching is that the dialog is presented faster and you can smoothly resize the "Places" pane.
> 
> Lukas Tinkl will try to optimize the Solid Udisks backend a bit to make it even faster, as this problem with device icons causing querying udisksd has impact on Dolphin start up time (and with this patch it has similar impact on the dialog show-up time).
> 
> 
> Diffs
> -----
> 
>   kfile/kfileplacesitem.cpp 3ada0c3 
>   kfile/kfileplacesitem_p.h 3c6bd30 
> 
> Diff: http://git.reviewboard.kde.org/r/107030/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dan Vrátil
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20121024/687e743e/attachment.htm>