Back

[Boudewijn Rempt]

On Monday 26 July 2004 14:37, Cyrille Berger wrote:
>
> KisPaintDevice {
>
> private:
>  KisTileMgrSP data() { return m_data; };
> public:
>  KisIterator iterator() { return KisIterator( m_data ); };
>
> private:
>  KisTileMgrSP m_data;
>
> };

The only problem with this scheme that I see is that you need a factory 
function for every type of iterator -- for the rest, okay. I was working on 
outdate assumptions.

>
> > * I'd like to have a richer set of iterators: over rects, over tiles (for
> > speed), and so on. Lines/pixel are okay.
>
> anyway, I don't see any differences between iterators over rects and over
> tiles.

A rect isn't the same as a tile. A rect can be any rectangle within a layer, 
cobbling over tiles if necessary, or fitting within one tile.

> I think we should have two "basic" iterators :
> - rects (walking on the image tile after tile)
> - line/pixel (walking on the image line after line)

I see a need for the following iterators:

* Rect -- Walk over a rect intersecting with (or all of the image by default) 
          pixel by pixel. The user can make assumptions about the order of the
          pixels presented.
* Fast -- Walk over the pixels of an image in the fastest possible way.
          This'll mean that the user cannot make assumptions on the order of 
          the pixels presented, and thus does not know where his next pixel is
          located. Useful for things like histograms. 

I really don't see much use in first iterating over lines, and within the 
lines over pixels. I don't mind those iterators to be present, but I probably 
wouldn't use them, since it makes my code more nested, and thus more 
complicated. And I mean, how often in all the filters you've created until 
now have you had the need to skip lines?

The things you want to do often boil down to:

for pixel all pixels in layer/selection/region
	composite pixel/channel
	blend pixel/channel
	make pixel/channel more/less transparent
	count pixel/channel
	copy pixel/channel to another layer
	mess with pixel/channel's color values
	render pixel/channel to 8-bit RGB (i.e. convert pixel/channel to other 
		representation)
	get pixels in 3x3 matrix around this one, and compute new value
		for this pixel.

Which is one degree easier than:

for line in all lines:
	for pixel in line:
		doStuff
	
> > * Oh, and I'd like a hint on what's going wrong in kis_histogram.cc. But
> > that probably has to do with the return type.
>
> there was two times ++pixelIt.

Ah, okay. Now when I get Krita to compile again, I can see whether my 
histogram has survived the holiday's little bit of coding.

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