Substrate implementation proposal

Bart Coppens kde at
Tue Apr 4 13:00:17 CEST 2006

On Tuesday 04 April 2006 08:39, Boudewijn Rempt wrote:
> I've been thinking about this, and this is my proposal:
Since I've unfortunately been occupied a bit with other stuff, I haven't 
followed this as much as I'd have wanted to. Hence, the stuff I might object 
to might be silly, etc.
Quoting from the proposal header file, mixed with my comments:
struct KisSubstratePixel {
    float height;
Why not make these virtual functions height() etc? Like you, I'm a bit worried 
about the 'XXX: Do we need more?' thing. If we'd make these virtuals, then 
the implementations could have it a lot more easy: for example if you'd only 
care about 'height', then the implementation could let the other functions 
return only 0, and save lots of memory. Similarly, if the implementation had 
_more_ values (not completely unthinkable, right?), making the implementation 
separate from the interface might be a thing to think about as well.

class KisSubstrate : public KShared {
Why not let this inherit from KisPaintDevice? That has lots of interesting 
functions that, admittedly not completely suitable at first sight, could be 
useful as well. In particular the iterators, _and_ the tile manager (which 
swaps! That's not something to bother the regular programmer of KisSubstrate 
with, and it would be handy, especially with image-sized substrates).
Now the basic concept through which the paint device would extend to 
substrates is iterators, and I think that with some hacking of custom 
iterators, it would be not too much of a problem (that's a hypothesis, of 

    virtual KisSubstratePixel * getPixel(uint x, uint y) = 0;
Why would that be 2 uints? I know that it's 'obvious' that you won't need a 
pixel at x,y < 0, and that with the current design it might be not a good 
idea. But it might be needed for some things like convolution and so?

So, in short: I'd make it inherit KisPaintDevice (probably with a custom 
KisColorSpace, that can be inherited as well for particular implementations, 
to match the substrate). But this might be very well all very silly and 
totally missing the point.

Bart Coppens

More information about the kimageshop mailing list