KisIterator, quantum and pixels

Casper Boemann cbr at
Mon Jul 5 08:38:49 CEST 2004


I'm planning to reimplement iterators to avoid using tilenum, but rather a
(row,col) pair.

However I have some comments/questions about the current implementation:

Why the use of templates. It's not like our iterators would ever be used for
anything but pixels. The iterators are way to tightlly coupled with the tile

True, we would like the pixel to be something other than just an array of
uint8. But templates are not useful for that. This would just set us up for
switches in the code. Btw channels don't have to be of equal size, think of
the yuv formats or even hsv. Not all colorspaces have uniform requirements
like RGB. Ofcourse the channels could follow the highest requirement, but
that would waste memory.

Actually what we have now with the QUANTUMs could easily be just what we
want if we interpret it correctly: A QUANTUM should mean a byte and that's
it! Pixelsize (aka depth) should mean the number of QUANTUMS (ie bytes) that
a single pixel occupies. ANY reference or interpretation of what the
QUANTUMS mean should go through the colorstrategy. If for the sake of (say)
efficient painting we need the alpha value outside the colorstrategy, then
the color strategy should be asked to extract the alpha value.

A color strategy could then implement that the first two quantums are the
red channel, the next single quantum is the blue, the next 3 quantums the
alpha and the next 2 the hue. (Yes I know - this is a very weird example,
but it would all be contained within a colorstrategy so who cares)

The current iterators are dead wrong on this in that they return and travel
individual QUANTUMs and not pixels. I was actually fooled yesterday, when I
posted the fix for the fill tool. Our iterators should use the pixelsize of
the paint device so that colorstrategies can handle the interpretation.

Regarding the names of iterators I think they should follow the naming
scheme of the rest of krita namely Kis<Data><Pattern> . I propose new
iterators build as replacements (actually renaming them ensures that they
will be used correctly as we'll need to rewrite every place they are used)
The iterators that I propose are:

// The superclass of all pixel iterators - possibly abstract

// A pixel iterator that covers a rectangle
KisPixelRectIterator(paintDevice, x, y, w, h)

// A pixel iterator that covers the extent of the paint device
KisPixelExtentIterator(paintDevice, x, y, w, h)

all iterators should have (a loose list, that needs refinement):
next() or ++
prev() or --
skipTile() // advances the distance of a tile. Used if you only want to
visit each tile
QUANTUM *() // pointer to the pixel data

best regards
Casper Boemann

More information about the kimageshop mailing list