How does krita render tiles to the screen?

[Patrick Julien]

On October 12, 2003 04:00 am, Michael Thaler wrote:
> Hello,
>
> > > 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?

The dirty flag was meant for actual rendering, the valid flag meant that the 
tile pointed to valid memory, i.e. memory that is still in-core.

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

For now, yes, but they could always use secondary storage, i.e. swap out parts 
of the image.

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

Effective STL by the same author is what you need to look at.

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

You need to get the gang of four book, life changing book, I promise :)

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

Yes and no, it depends, even for file preview (in konqy) and printing, the 
document gets called, but again, I was never sure why the paint stuff was 
actually in KoDocument instead of KoView, I believe that the default was in 
KoDocument and any other representation went in the view.

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

Works for me.  However, again, see the "Hacking Krita" thread in this list 
archives, it actually holds much information about Krita vs. Krayon and what 
needs to be done in Krita eventually.