Rework of iterators

[Casper Boemann]

> > 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.
> no we have decided to have two type of iterrator, one using line and then
> column (current system) and an other going throuh tiles.

No. What we have decided is to only have pixel iterators and not quantum
iterators. The minor issue of line and colum versus Rect is of no real
concern and yes we could have both.

And your changes is one more step down the road of quantum iterators, which
locks krita into a cripled architecture. By shifting to pixel iterators now
a flexible architecture can be achived with very little effort. If waiting
until later then too much work would have been done for an effortless shift.

Krita is at an important crossroads - lets please go the right way - as we
have already decided.

> > 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.
>
> There is no need for them to be virtual for the first released, we have
> decided that QUANTUM/Q_INT8 were the standard for that release, and that
we
> will decide how we get ride of it after.

.. this has nothing to do with the methods of the iterators needing to be
virtual. If a colorstrategy method is going to take any kind of iterator (eg
Rect, Line or Path), it needs to take a generic baseclass with virtually
overloaded methods.

> Look at the changes, I made you should not return a pointer to the data
but
> rather a KisQuantum, because in a KisQuantum we can take the selection
into
> account.

Again: access to quantums is the sure way to a crippled architecture.

> > 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
> for the comparison, you just have to compare the tilenumber, and if two
> iterrators are on the same tile, you just have to compare the position in
the
> tile.

That won't do. Fundamentaly we need to stipulate that only comparison with
begin and end is allowed. Comparison with iterators defining other rects are
a no-no. If we stipulate this (I think we should) then your description is
indeed enough (and we can traverse tile by tile)

Btw, tilenums are disappearing in the very near future, but that is of no
real concern to this issue.

best regards
Casper Boemann