[Digikam-devel] [Kde-imaging] Exposure Blending tool finalization...

[Gilles Caulier]

2009/12/25 Marcel Wiesweg <marcel.wiesweg at gmx.de>:
>
>>
>> All zoom and paning features are controled by QT4::QGraphicView. No
>> more. Code is very simple, but... not very fast.
>
> Yes, it cannot be. In fact, you will get bad performance combined with bad
> quality ;-)
>
>        d->pixmapItem->setPixmap(QPixmap::fromImage(image));
>
> For digikam, we will use DImg, here it's QImage. Doesn't matter.
> What happen when "image" is to be painted at zoom 2.0?
>
> The image is converted to a pixmap. Depending on the underlying graphics
> engine, this implies color format conversion (in the best case to
> ARGB32_Premultiplied, in worse cases e.g. to ARGB8565_Premultiplied or RGB16)
> and, for the case of X.org, transport by Xlib protocol to the server.
> For scaling, in the case of X.org, the data need to be tranferred from the X
> server to the application, converted to a QImage, scaled by a factor of 2.0,
> converted back to QPixmap, and again transferred to the X server, where it is
> finally blitted to the window surface.

But it's the same for Digikam::Dimg excepted that caching pixmap is

- more ingenious. We compute caching pixmap from DImg only when we
need to paint scrollview content.
- We use tiled pixmap, as Gimp and photoshop do.
- faster because we only show what we need to see on scrollview.
- We use a large part of memory to store cache data (70Mb if remember)
- scaling code from imlib2 is really great there.

I suspect that QGraphicView show pixmap inside a QLabel and resize
whole content on the fly (whole Pixmap). This is definitively a bad
way.

Sure it work fast with small image, which is usefull to display with
drawing items (not pixmap) but not really to display a large picture.

Gilles