[Digikam-devel] dcraw v8.27, -2 option problem
Marcel Wiesweg
marcel.wiesweg at gmx.de
Wed Aug 2 22:08:00 BST 2006
> > > P.P.S.: BTW, digikam really rocks - only for browsing through
> > > a sequence of images I still use gqview which is quite a bit
> > > faster (I think that one of the (if not *the*) main factor is
> > > that gqview caches the next picture in the row).
> > > Do you intend to implement caching of images/histogramms etc.
> > > for 0.9, or is this a possible post 0.9 feature?
> >
> > We are caching images.
>
> In what situation?
> For example, if I have two 3.5 MB (8Mpx) .jpg and have the "Colors"
> sidebar with the histogram open, changing back-and-forth
> between these images, one gets "Loading imae" and
> then "Histogram calculation in progress".
>
> In the Image Editor it takes a bit more than 4s to move
> from one image to the next (again, on my slow machine).
> Going back to the previous images takes the same amount
> of time.
> So to me it does not *feel* as if there was any caching,
> but maybe I am doing things the wrong way ...
You are right, something is wrong...Some images are not cached...
TODO list is growing, time is rare :-(
>
> > Currently, we do not preload. The infrastructure is
> > there, it's probably only a few lines of code. I decided not to do it
> > because there were some problems, don't know what exactly any more.
>
> I see. Yes, preloading would be very nice
> (maybe even something like the next n images, with n being
> user-adjustable, as it depends on the amount of available RAM,
> and caching of images/histograms of m previous images?)
The cache size is fixed, 40MB or 60MB, don't know. Took that number from some
older implementation from Renchi.
>
> Just some dreams of a happy end-user ;-),
>
> Many thanks for all your great work,
>
More information about the Digikam-devel
mailing list