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

[Gilles Caulier]

2007/4/6, Marcel Wiesweg <marcel.wiesweg at gmx.de>:
>
> > 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?


no, and if you take a look in my patch, i don't use it. Preveiw loading
still used...

This way, we could also
> experiment with faster scaling algorithms.


Tested. It's work. It's more faster than QImage::smothScale() but similar
than QImage::scale(). Backport is here :

http://digikam3rdparty.free.fr/misc.tarballs/smooth-bresenham/

of course result is smothed with this algo insteas QImage::scale() is not...


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.



Ok, i close it...

Gilles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20070406/0841ff3b/attachment.html>