High-level pixel access methods

[Boudewijn Rempt]

Perhaps a contradiction in terminis, but as noted a little while ago it would
be nice to have efficient, high-levle pixel access methods. I said I would 
think about a proposal.

We already have setPixel() and pixel() in KisPaintDevice, but one thing you 
cannot do is:

 thisDevice -> setPixel(otherDevice -> pixel())

And besides, I strongly suspect both methods of being very slow -- but I am 
not sure, of course, not having figured out how to do profiling in any other 
language than Python of Java yet.

The other thing is that it would be nice to be able to retrieve an iterator 
that efficiently moves over the pixels in a rect of a KisPaintDevice.


I came across this problem when hacking support for matrix transforms in 
KisPaintDevice using QWMatrix. Couldn't figure out how to loop with pointers 
over all the bytes in the tile manager without messing tiles myself -- a sure 
sign that the interface isn't yet high-level enough for mere mortals like me.

I would like something like:

in KisTileMgr:

KisPixelDataSP getPixel(Q_UINT32 x, Q_UINT32 y);
void setPixel(KisPixelDataSP pixel, x, y);

And either a readPixelData() that doesn't copy all the pixels, or an iterator
over the pixeldata (I prefer iterators over and above pointer arithmetic 
loops, even if I know how to loop with pointers, and don't know yet how to an 
iterator in C++. Besides the iterator could hide the tiles more easily, I 
think.)

Would this be possible?

(A third problem is that once we need to store more than five QUANTUM's of 
data per pixel, we're currently hosed, and if I get down to implementing a 
kubelka-monk colour strategy, I need at least six QUANTUM's, and possibly 
more. And there may be places where it would be preferable to have growing 
stack of colour data, for instance when mimicking glazes) So making the 
pixeldata less dependent upon MAX_CHANNELS and the rest
of the code less dependent on there always being the same number of bytes in a 
KisPixelData struct would be nice.)

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