Rework of iterators
Casper Boemann
cbr at boemann.dk
Sun Jul 11 17:08:48 CEST 2004
> Hello,
> following the talk on the ml on the last few days, I have change the API
of
> iterators, I have convert the krita code to the new API, I hope I have
broken
> nothing. If the new API is alright with everyone I will start working on
the
> second type of iterators.
Cyrille, I'm confused. Have we not decided to implement pixel iterators, and
eventually let the current iterators become obsolete.(except perhabs the
line iterator). It seems to me that your rework is slightly wasted.
Regarding pixel iterators: I've implemented a Rect iterator (attached, but
not yet ready for prime time), to which I have the following
questions/comments.
I have made all the methods virtual, but I'd really like them not to be. I
fear virtual methods carry too high a performance penalty.
The methods of the iterators should be virtual, if we are to allow different
backends for the paint device. As I have said before I don't think there is
a need for different backends. And if needed we can make the methods virtual
later, so fo now this is not the deciding factor.
The methods should also be virtual, if we are to give them as arguments to
functions. Personally I think that we shouldn't give iterators to the
colorstrategy (the loop code albeit small would have to be repeated for
every colorstrategy). If we fix the iterator to the colorstrategy to a rect
iterator (as a sepcial optimization for compositing), then it needn't have
virtual functions.
On the other hand other functions (outside the colorstrategy) might want to
take iterators as arguments.
If we are willing to forego these polymorphic uses of iterators we can keep
the metods non virtual.
The final argument for keeping them non-virtual is the comparators. How do
you compare a rect iterator with a path iterator. I can't see how. This is
why I have implemted a simple hack in the <= comparator.
I vote for non-virtual but what do the rest of you think given the
implecations ?
Per recomendation of Cyrille I walk through the rect one whole tile at a
time. Performancevice it seems a smart trick, but this gives a non
traditional traversal, which raises question when comparing two iterators.
You could either compare in traversal order, or in "line then x" order, but
neither would be like you expect. I am afraid that a rect iterator would
have to have "whole line after whole line" traversal
Note that I still regard my implementation as a technology demostrator. And
I strongly suggest that no one should use any iterator except for testing
before we are very certain that we have got it right.
Best regards
Casper Boemann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kis_pixel_iterator.cc
Type: text/x-c++src
Size: 4865 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20040711/19469bf5/kis_pixel_iterator.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kis_pixel_iterator.h
Type: text/x-chdr
Size: 3946 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20040711/19469bf5/kis_pixel_iterator-0001.bin
More information about the kimageshop
mailing list