[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Walkers pt.2
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2010-01-08 14:42:45
Message-ID: ae32c1ef1001080642s57e58a95j7b32b634e160b3db () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
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 | <---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's \
siblings... until we reach root layer.<br><font face="courier new,monospace"><br> \
</font>Let's imagine we dirtied layer "paint3". 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 "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!<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>
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic