Substrate implementation proposal

[Boudewijn Rempt]

On Tue, 4 Apr 2006, Bart Coppens wrote:

> 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;
>     etc.
> 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.

The problem is that I want to decouple the substrate definition from the colorspaces:
I want a substrate definition that can be used with any media colorspace because
I want to be able to combine, say, chalk and watercolor on the same substrate.
I'm not sure how feasible this is, but it would be very cool.
> 
> 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 
> course).

The problem is the tile backend: we want two kinds of substrate. The kind where
we tile a smallish area for the image dimensions, and the kind where we generate a
substrate as big as the image (and resize when the image resizes). Because
the datamanager backend isn't pluggable, we cannot use KisPaintDevice here.

My first idea was to create a special colorspace and a special layer subclass
and use paint devices, but that didn't work because of the above reasons.

Of course, we could decide to solve this at a lower level, by making it possible
in the datamanager to use a repeating tile.

>     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?

True.

> 
> 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.

Not at all -- it had crossed my mind, too.

Boudewijn