How does krita render tiles to the screen?

Michael Thaler michael.thaler at
Sat Oct 11 12:01:43 CEST 2003


> 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

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

> 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[]!)

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

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

We shall not cease from exploration, and the end of all our exploring 
will be to arrive where we started and know the place for the first time.

More information about the kimageshop mailing list