Substrate implementation proposal

[Casper Boemann]

A pattern of a fixed size is a limitation we cannot live with

We can always reuse the tile manager without reusing the paint device.

so if KisSustrate has someting like

getPixel()
{
  switch(datatype)
     case tiled
        tilemanager->getpixel(x,y)
     case pattern
        pattern->getPixel(x%size, y%size)
    case function
       function->getPixel(x,y)
}


Possible in a more OO way but you get the idea.

And though we have talked about changing tilesize, that is only a question 
of optimizing, not for pattern. imho

best regards
Casper
----- Original Message ----- 
From: "Boudewijn Rempt" <boud at valdyas.org>
To: "Krayon (KImageShop)" <kimageshop at kde.org>
Sent: Tuesday, April 04, 2006 1:56 PM
Subject: Re: Substrate implementation proposal


> 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
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>