Substrate implementation proposal

[Boudewijn Rempt]

On Tue, 4 Apr 2006, Bart Coppens wrote:

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

Still, we need to arrive a basic set of properties all substrates have. 

> 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 ;-)

True. I had thought about that but I wasn't sure whether it would be worth
the bother.

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

Well, the methods of the datamanger are not virtual, so we'd need to have another 
paint device class to use the other datamanger. 

> 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 :-(

I'm not sure that would be a big problem. Leonardo -- do you think a tile limitation
for substrates of 64x64 would be problem? Otherwise -- we've always wanted to make
the tilesize configurable, right :-)


Boudewijn