koffice/krita

[Boudewijn Rempt]

On Friday 17 February 2006 14:19, Adrian Page wrote:

> I think part of the problem is that updating the projection is done
> inside notify. If that was done only when the ui asks the image for part
> of the projection, compositing could be left until the ui is about to
> use the data. That would mean the ui could ignore notifies while loading
> the image, or doing some multi-command action, and only do one composite
> at the end. The image could maintain a dirty rectangle that gets added
> to by each notify and removed on composition.

That used to be the case, more or less, and without really having a dirty rect 
(or perhaps better, list of dirty rects) but I changed that in version

http://websvn.kde.org/trunk/koffice/krita/core/kis_image.cc?rev=461961&view=rev

A year or two ago, iirc, I played with a system that would keep a list of 
dirty rects and a thread or timer that would composite the dirty bits every 
so often.

Currently, the projection has been moved into the group layers (and the adj. 
layers, in some sense). I'm trying to convert calls of notify() to more 
fine-grained calls setting only the right layers to dirty (which should 
perhaps be setDirty(rect)) and compositing only those groups that are dirty.

What I would like would be to get rid of notify() completely and only use the 
dirty setting in the layer, that we we know which groups (and if there are 
adj. layers, from which point in the group) we should recomposite.

Also: we started to use the projection in things like flatten, working from 
the assumption that the projection would always be up-to-date.

-- 
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/20060217/dc843d22/attachment.pgp