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

[Marcel Wiesweg]

> 
> 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.

What should be done?
Never scale a pixmap. Scale the DImg and only convert to pixmap the data that 
will 1:1, unscaled, be painted on screen.
For caching to improve painting performance, cache only this pixmap data, do 
not cache pixmap data which still needs scaling. (You can scale the original 
image, but that's not for painting performance)

QGraphicsView can give us a lot to have items on the preview, as needed for 
some image plugins, but - I tried to say that during the coding sprint - I 
dont believe its scaling facilities can be used out of the box.

As soon as the painter has a transform, like calling scale() on the view, 
painting image data will be slower.
I would experiment with a custom item which is ItemIgnoresTransformations and 
the DeviceCoordinate cache mode, or resetting the painter transform before 
painting.
We must also keep in mind that in the case of scale()ing the view, items on 
preview, like handles for perspective adjustment, will grow and shrink as 
well. Perhaps they need ItemIgnoresTransformations.

They may be other, better approaches as well.

Marcel