notify() and renderToProjection() again

[Boudewijn Rempt]

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 
a rect,
  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  
  QPainter::drawImage().

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

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050919/ddbd0972/attachment.pgp