Walkers pt.2

[Dmitry Kazakov]

>
> I'm principle ok with the naming (though it would be nice to add
> "projection"
> to the walkers, I think),

It has a word "Merge" inside. Now every layer has it's own "projection". I
guess it should be called more general.


> but I'm wondering about the performance impact. It
> has become quite a complex beast! Have you any insight in the performance?


Yeah, there surely be some performance penalty. Though every parallelization
technique has it's penalty on uniprocessor machine.
You see, now the merge is done in two steps:

1) walker.collectRects(node, rc);
2) merger.startMerge(walker);

The second step was indirectly present in a previous version. The first one
is completely new. And the slowest part in the first step is allocating a
stack of size N, where N - number of layers. (I think this is the slowest,
should check)

Though we shouldn't forget that this very "beast" is a small bugfix actually
=) It fixes "border-effect" problem, that can't be really fixed in other way
(read: i don't know how to fix it in other way:) ). And it creates the
ground for safe parallelization.

PS:
I should add a creation of a simple performance benchmark to my todo-list...


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