How does krita render tiles to the screen?

Michael Thaler michael.thaler at
Sun Oct 12 11:00:02 CEST 2003


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

I still don't understand it. Each tile has two bools: dirty and
valid/invalid. I grep'ed for both and I think actually valid/invalid
actually indicates the state of the tile. Maybe dirty has something to
do with swapping?

Now, the rendering code, that actually renders the tiles to the screen
is in KisDoc (and in KisColorStrategyRGB which is called from
KisDoc). But the rendering code is not making any use of the
valid/invalid flag of the tiles. I thought the whole point about
setting tiles valid/invalid is to know if they should be drawn to the
screen or not? Or am I getting something terribly wrong here? What is
the intention of valid/invalid?

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

What exactly do you mean? The tiles are hold in memory, anyways,
aren't they?

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

I guess I have to buy "More Effective C++" or some similar book pretty
soon. I have a basic understanding of C, C++ and Java, but there are
probably many more advanced and usual things which I don't know. (I'm
not a professional coder).

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

I have no clue what a design pattern is, sorry. But anyways, I think
KisDoc is not really that complicated, it is a lot of XML stuff I am
not interested anyway.

> 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 

I was wondering about that, too. Shouldn't the actual drawing be done
in KisView and not in KisDoc?

I just realised that you can load more then one image in seperate
layers and go to the layers-dialog and change the opacity of the
topmost layer. Looks really cool! Great work. (There seems to be a
little bug, though, because I can only change the properties of one


More information about the kimageshop mailing list