# Design of KisCurveIterator

Cyrille Berger cberger at cberger.net
Sun May 28 01:56:49 CEST 2006

```Hello,
I want to introduce a new kind of iterator, those iterator would follow a line
defined by a function (think of an iterator following a wave defined by
cosinus for some deformation filter, or think about a distortion correction
filter).

In the example I will used to explain myself I will take a CurveIterator
following ( x=10*cos(t/10) y=10*sin(t/10) t >=0).

As those iterators follow a curve they will be never precisely on one pixel,
and therefor would need to access four pixels, and subsample them. For
instance, for t = 0, we have x= 10, y=0, it's precisely one pixel, but for
t=10 we have x=5.4 y=8.4.

the thin virtual layer of the other iterators, but curve would have one
too)  : KisCurveFunction, KisCurveIteratorPixel (in core/ ) and
KisTiledCurveIterator (in core/tilemanager)

KisCurveFunction is an interface which should be inherited to implement the
function describing the curve. I am not quiet sure yet if it's best to use
directly the function or its derivative, or both, but it would look like:

class KisCurveFunction {
public:
virtual KisPoint valueAt(int t) =0;
//	virtual KisPoint derivativeAt(int t) =0;
};

KisCurveFunction should be accessible by the at least the
KisTiledCurveIterator, and plugins. That's why I was thinking to put in

The big question without answer yet is wheter the subsamplinging is handled by
the iterator or by the user. For reading, it's pretty easy how to do it. But
I am little bit skeptical for writing, in the use I have in mind I don't need
writing, so maybe this iterator should be read only ?

KisTiledCurveIterator would manage the tiled (it has four tiles to manage).
KisCurveIteratorPixel is the core wrapper to hide the tiled manager, and would
be in charge of subsampling.

Bart asked me on irc why not use the allready available iterators ? Good
question, but:
1) as CurveIterator needs subsampling, and need access to four pixel, so with
current iterators I do fair that either by using four iterators or somehow
hacking around to have one, we will have a serious performance problem
(changing tile is very expensive, and I do think that there would be a
problem when iterating close to the border of a tile)
2) current iterators' API does not allow to implement CurveIterator in an
efficient and clean way, and transforming their API would, I think, damage
their purpose. As clearly, the CurveIterator needs something close to random
access in the image. I mean random path in the image.

--
--- Cyrille Berger ---
```