koffice/krita

[Boudewijn Rempt]

On Friday 17 February 2006 15:09, Adrian Page wrote:

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

How about this:

* all calls to KisImage::notify() become calls to KisLayer::setDirty(rect). 
KisLayer::setDirty() informs the image of the new dirty rect, the image keeps
a list of dirty rects.

* access to the rootlayer's projection is done through KisImage.  KisImage 
then consolidates the dirty rects into a list of non-overlapping dirty rects. 
That would be fairly cheap, I guess, and finally starts to merge.

I'm not sure whether we should allow access to the cached paint device of the 
adj. layer and the group layers outside the core library.

-- 
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/9c6d3177/attachment.pgp