Substrate implementation proposal

[Bart Coppens]

On Tuesday 04 April 2006 13:07, Boudewijn Rempt wrote:
> 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.
Well my idea doesn't prohibit that specific (and admittedly _very_ cool) idea: 
since all substrates would still follow a basic interface, they could be 
still interchangeable. Maybe without all the 'original' features or so, but 
still work.

A bigger problem would indeed be if you'd start _writing_ to them (you know, 
like carve something in the 'paper' by changing the height), since it's an 
interface, not an actual 'structure'. But you have that problem as well 
(though because of a different reason) with your proposal, since:
virtual KisSubstratePixel * getPixel
doesn't actually return a const struct, so you'd be able to write back to a 
structure that is possibly _tiled_. You could get by that by adding 
writePixel, but then we'd have to keep track of which tile needs to be used 
when. And then we're getting awfully close to reimplementing our own tile 
manager ;-)

> 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.
Says who ;-)
protected:
    KisDataManagerSP m_datamanager;
But rewriting the datamanager would be not a fun thing to do, and, the more I 
think about it, the more problems changing the iterators would give as well 
(speed-wise).

> 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.
Yeah indeed :-/

> Of course, we could decide to solve this at a lower level, by making it
> possible in the datamanager to use a repeating tile.
But that'd limit us (at least initially) to a fixed 64x64, and that might not 
be a good limitation either :-(

Bart