koffice/krita

[Adrian Page]

Boudewijn Rempt wrote:
> 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.

I guess it all comes down to deciding at what time dirty layers are made 
undirty and at what time a signal is emitted to indicate something has 
changed. They may or may not be the same. From a performance point of 
view, which this is mainly about, certainly the compositing wants to be 
left as late as it can, so we can combine multiple dirtying operations 
into one undirtying one.

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

This is part of the problem I think, because certain parts of the code 
assume the projection will be up-to-date, but some parts of the code 
don't enforce this, i.e. addLayer. It's hard to know which parts of the 
core require the caller to do a notify, and which don't. Someone writing 
a plugin who isn't intimate with the internal workings of the core 
really has no idea at the moment.

Adrian