The reasons why i rejected an idea of using regular visitors and wrote this heavy infrastructure instead:<br><br><font face="courier new,monospace">     /*<br>
      +----------+<br>
      |root      |<br>
      | layer 5  |<br>
      | group    |<br>
      |  paint 4 |<br>
      |  paint 3 | &lt;---dirtied<br>
      |  adj     |<br>
      |  paint 2 |<br>
      | paint 1  |<br>
      +----------+<br>
     */</font><br>
<br><br>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&#39;s siblings... until we reach root layer.<br><font face="courier new,monospace"><br>
</font>Let&#39;s imagine we dirtied layer &quot;paint3&quot;. The order will be the following: paint3, paint4, group, paint5, root<br clear="all">Generally, it can be implemented using visitors.<br><br>2) NeedRects should be collected be collected in the following order: root, paint5, group, paint1, paint4, paint3, adj, paint2<br>
<br>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.<br>
Once we collected all this, we can wait until other threads finished and start a merge afterwards.<br><br><br>As i understood, a &quot;visitor&quot; 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!<br>
<br>The task of all these classes is to call these virtual methods in a right order.<br><br><br>PS:<br>Btw, KisAsyncMerger still uses modified KisMergeVisitor for updating original() of all the layer.<br><br>-- <br>Dmitry Kazakov<br>