notify() and renderToProjection() again
boud at valdyas.org
Mon Sep 19 10:16:57 CEST 2005
I've now succeeded in separating the compositing and the painting onto a
canvas, but I find the code that handles image updates and canvas updates a
little confusing still. I'll summarize what I think what's happening here:
* If you change the image, you should call KisImage::notify(), preferably with
because otherwise the entire image is re-composited.
* KisImage::notify() emits the signal update(KisImageSP, rc)
* There is also a signal emitted from KisImage called imageUpdated(KisImageSP)
This is emitted by KisImage::layerAdd, layerRemove, setLayerProperties.
* update(KisImageSP, rc) is connected to KisView::imgUpdated,
imageUpdated(KisImageSP) is connected to KisView::imageUpdated().
* KisView::imgUpdated calls updateCanvas.
* KisView::imageUpdated calls canvasRefresh
* There must be a difference between the two, because
KisView::scaleCurrentImage, rotateCurrentImage, shearCurrentImage call both
KisView::imgUpdated and KisView::imageUpdated
* And there is: both call paintView, but canvasRefresh also calls
m_canvas->repaint(). And, updateCanvas takes a rect, canvasRefresh doesn't,
but creates the rect from width of the canvas pixmap.
* And KisView::paintView calls KisDoc::paintContent, which calls
KisImage::renderToPainter(), which doesn't composite, converts the
projection to a QImage and paints that onto the painter with
(Notice that there also a signal called layersUpdated emitted from KisImage,
often in concert with ImageUpdated)
I guess we're going to have to cleanup this dish of bolognese...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050919/ddbd0972/attachment.pgp
More information about the kimageshop