Walkers pt.2

[Dmitry Kazakov]

The reasons why i rejected an idea of using regular visitors and wrote this
heavy infrastructure instead:

     /*
      +----------+
      |root      |
      | layer 5  |
      | group    |
      |  paint 4 |
      |  paint 3 | <---dirtied
      |  adj     |
      |  paint 2 |
      | paint 1  |
      +----------+
     */


1) We should collect changeRect in not a linear way. First we should iterate
through all the siblings lying above then go to the parent, iterate trough
it's siblings... until we reach root layer.

Let's imagine we dirtied layer "paint3". The order will be the following:
paint3, paint4, group, paint5, root
Generally, it can be implemented using visitors.

2) NeedRects should be collected be collected in the following order: root,
paint5, group, paint1, paint4, paint3, adj, paint2

3) After we collected all this we should stop and wait. What if some other
thread is writing to one of our needRects? That is why now merge process is
split into two stages: one - collecting rects and another - merging itself.
Once we collected all this, we can wait until other threads finished and
start a merge afterwards.


As i understood, a "visitor" is a virtual method for different types of
objects, that is stored outside these objects. In our case, we do already
have all the needed virtual methods (need/changeRect) inside KisNode. This
means there is no use of visitors!

The task of all these classes is to call these virtual methods in a right
order.


PS:
Btw, KisAsyncMerger still uses modified KisMergeVisitor for updating
original() of all the layer.

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100108/4076fcbd/attachment.htm