Iterator requirements

[Casper Boemann]

> The current implementation of iterators shows the way forward, and perform
> quite surprisingly well, but we'll need to extend and refine the
> implementation, and carry forward the use of iterators throughout Krita so
> that it becomes the only way to access image data. Direct tile manager
access
> should be discouraged, if not made impossible (can C++ do that? no package
> private classes, are there?).

Agree.

> The tile manager loads image data on demand from Krita's file format,
> and, where possible, from other image types that allow on demand loading
> of portions of the image.

Perhabs but if so it needs to be decoupled.

> The tile manager manages undo data (currently it's KisPainter that does
this,
>     but it makes sense to push this responsibility down).
yes there are benefis to that, but the way we do this should be thought
through

> * Iterators
>
> Iterators offer random and linear read/write access to channels, pixels
and
>     2 dimensional arrays of pixels.

Not channels, and 2 dim arrays just complicates things.

> Iterators return pixel data as a vector/array (whatever, but preferably
not
> a pointer to a amorphous chunk of bytes*) of bytes which can be
interpreted
> by the colour strategy as a colour.
> *) Although I can probably be talked out of that by showing me some real
> perfomance measurements. Always having to check boundaries will soon
become a
> real pain.
No checking is needed.

> Colour strategies can render their pixels to display RGB format (i.e. a
>    QImage).
Yes but later it should be done with the aid of lcms that gives us ICC color
profiles

best regards
Casper Boemann