finalizing the Iterator API

Boudewijn Rempt boud at valdyas.org
Wed Jul 7 11:16:09 CEST 2004


On Wednesday 07 July 2004 10:52, Casper Boemann wrote:
> > Note that you often need quite different rendering code for the same
> > basic colour strategy with different channel sizes -- check the way
> > exrdisplay calculates the display pixels for a 16-bit image in OpenEXR
> > 1.2.0.
>
> Templates allow typespecific parts. I know you asked this earlier, but look
> for specialization of templates in any comprehensive C++ book. I even have
> a way of doing this without using this feature, should the compiler not
> support it.

Oh, good. Now I think we've threshed out most of the design; we've even got a 
use case. As far as I'm concerned you can start implementing; do not replace 
the current kis_iterators.h yet, put the pixel iterators in a different file
so they can co-exist for some time so we don't have to break current 
functionality.

So, to summarize:

* PixelIterators return a pointer to Q_UINT8 (not QUANTUM, since that is a 
remnant from the days Krita depended on ImageMagick for its core, besides 
that gives the impression of being interpreted data already.)

* Iterators use begin() and end() -- they must have as much as possible the 
same syntax as Qt's iterators.

* Colour strategies interpret the data delivered by the iterators, they can,
for instance, return a vector of channel values or a KoColor.

* Colour strategies have a ChannelInfo object (which I'll extend tonight) that 
describes the way *Q_UINT8 will be interpreted

* Ultimately, I want to get rid of much of the machinery in kis_global.h, like
QUANTUM and its ilk, and the PIXEL_XXX definitions that describe the position 
in an array of QUANTUMS for each channel.

Steps to take:

1. Do the basic iterators (straight pixel through image or subrect of image 
with selection) -- other return structures (kernel) can come later, as can 
iterators that move in devious ways through the image.

2. Extend the current colour strategies to interpret the data and return 
something useful for filters and algorithms.

3. Refactor kis_painter to use iterators and colour strategies (pass iterator 
to colour strategy for composition).

4. When Krita uses the iterators and nothing else, hide the tile manager more
thoroughly.

While doing this, I would tremendously appreciate it if existing functionality 
is not broken. In particular: image import, paint tools, layer composition -- 
because those are the essentials that allow us to test Krita.

(By the way, I'm going away next Friday for a week or two and although I'm 
taking a laptop, I won't have net access, so I can't check on progress. But 
there are plenty of people with commit access, so there's no reason to quite 
working just because I'm not available (like what happened the time I was 
away nursing my mother).)

-- 
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi


More information about the kimageshop mailing list