How does krita render tiles to the screen?

[Patrick Julien]

On October 11, 2003 05:01 am, Michael Thaler wrote:
> Hi,
>
> > No, swapping means swapping out to disk, or in the case of an unmodified
> > tile, simply destroying the tile data so that can be read back from the
> > original image at one point.  For a very large image, most of the image
> > might not be viewable in the viewport, so we can always throw parts of
> > the image if need be.
>
> O.K. now I see. But as far as I see, this is not implemented yet, also
> KisTilecache is not implemented.
>
> Dirty probably means, if a tile is modified or not, so that krita
> knows if a tile has to be repainted or not. But what does valid then
> mean.

Ouch! You got me, I really don't remember, it's already been 9 months.

>
> There are also lock(), lockAsync() which I don't really
> understand. The code is commented out so it does not seem
> necessary. But what is the intention? Is it possible that a tile is
> accessed by more then one thread? Or did you just include this just in
> case?

No, this is not entirely for multiple threads, there was an experiment at one 
point in Krita with worker threads, yes, but locking the tile also makes sure 
it's actually loaded into memory, hence the lockAsync, reads the tile in 
asynchronously so that Krita can keep working.

>
> > KisTileMgr helps upper layers have a unified, simple interface to find
> > and manipulate tiles.  However, lower layers (swapping, for example, if
> > it's ever written) would find this complicated to use, you see, krita,
> > being a koffice application, supports multiple frames, documents, etc. 
> > Layers, channels, masks, images for all the documents are
> > KisPaintDevices, this is a whole lot of KisTileMgr's to go over,
> > KisTileMediator allows a lower layer (like swapping) to access tiles by
> > different criterias without actually worrying where tiles actually are in
> > memory since it simply does not care.  Here we would access tiles by
> > their age, not by which layer etc.
>
> Rereading the code this morning, I think I have a basic understanding
> of KisMediator and KisTileMgr now. But why are you doing reference
> counting in KisMediator? I thought this is already handled by the
> KSharedPtr (which is actually really nice, no more delete[]!)
>

Ah, there is a little trick there, I can tell you, but I'm sure you want a 
little more time, otherwise you would be kicking yourself :)  Anyway, let me 
know.

In any case, yes, preaching other C++ coders about the benefits of using 
vector, string and smart pointers makes me happy :)  Have a look at 
boost::shared_ptr and boost::scoped_ptr.  You may also be interested to look 
at the bug report I filed about KSharedPtr on kdebugs for an interesting 
discussion on smart pointers.

> > Nope, no loading or saving here, this has to stay independant of the
> > actual storage implementation, Image here is only an in-core
> > reprensentation.
>
> O.K., I have to read KisImage, KisDoc etc. Unfortunately this is a lot
> of code.

Not really, the loading/saving of images follows the builder design pattern, 
if you understand that, you're already half way there. The KisDoc rendering 
code I do find a little weird tho, Koffice puts a pure virtual for the 
drawing of views in KoDocument, so I had to put in there :)  However, I'm not 
sure if I followed the real intent that the designers of Koffice-lib had in 
mind when I did this by putting this in KisDoc.

>
> > This is by using the colorspace stategies, but they are pretty raw in
> > their current form, the previously mentioned "Hacking Krita" thread has
> > all the details.
>
> As far as I understand this now, KisGuide is doing the actual
> rendering to the screen, isn't it? I have to look at the code.

No, it isn't.  The aftermentioned thread on this list has all the details.  
KisGuide are the actual guides you see when you click on a scoll bar and drag 
it into the canvas, there a little lines for the artist to help him draw 
better.