[Digikam-devel] extragear/graphics/digikam/utilities/imageeditor/canvas

Marcel Wiesweg marcel.wiesweg at gmx.de
Fri Apr 6 17:38:49 BST 2007


> 2007/4/6, Marcel Wiesweg <marcel.wiesweg at gmx.de>:
> > > However, I think it would be nice if the time for "Loading ..."
> > > would be shorter (even on a Core 2 Duo with 2 GHz and 2 GB RAM
> > > it is about 1s to go from one image to the next).
> > > This is also true when going back-and-forth between two images
> > > (wasn't there some caching supposed to be active?)
> >
> > Yes there is caching. Going back to the previous image is fast here.
> > There is no preloading currently in the editor - it is not enabled.
> >
> > Marcel
>
> And I would just said one word about my experimental implementation here :
>
> Since i have works hard into canvas implementation, especially to speedup
> rendering of image, I have used editor canvas to render preview image on
> Preview Mode from Album GUI. It work nice. Now we can zoom in zoom out into
> preview. It's fast. This way will solve this B.K.O file :
>
> http://bugs.kde.org/show_bug.cgi?id=140131

Do you need DImg objects from the preview then? This way, we could also 
experiment with faster scaling algorithms.
Problem is loading from memory. If necessary, we still need to load using a 
QImage, it supports loading from memory...

>
> And Marcel, what news about this one :
>
> http://bugs.kde.org/show_bug.cgi?id=132047
>
> It's can be closed ?

Yes, there is nothing I can think of right now that we have left to implement 
to make loading faster.

>
> Also, to give an easy comparing tool, Canvas will be the best solution :
>
> http://bugs.kde.org/show_bug.cgi?id=135048
>
> It's easy to do : two canvas instance on the same QMainWindow, with
> scroollin synchronized...
>
> Gilles



More information about the Digikam-devel mailing list