On October 10, 2003 02:35 pm, Michael Thaler wrote:
> Hello,
>
> I was looking at kritas tile/rendering. I think basically it works
> like this:
>
> - the pixel data is stored inside a 64x64 pixel tile. The stile also
> stores some more information like its current status etc. The tiles
> can also make a copy of themselves and they can also swap themselves
> (but I am not exactly sure what that means. I guess they make a copy
> of themselves and when the tile is modified, the swapped version can
> be used for undo? Is that right?). Then there is also some cache stuff
> which is not used?

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.

>
> - Then there are the kisTileMgr and kisTileMediator classes. They
> manage the stiles, set there status to clean/dirty, valid/invalid
> etc. They can also delete tiles, add tiles etc. They can also return
> the number of the tile that contains a specific pixel etc. But I did
> not really understand the difference between the two classes. It looks
> like they do pretty much the same. Can you please briefly explain me
> the difference.

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.

>
> - Then there is the higer level kispaint_device which is used by
> kispainter to draw something.

yes

>
> - kispainter does the actual drawing options.

Please see the "Hacking Krita" thread recently posted here to get some details 
on this here.

>
> I did not understand all the details, but in principle I think I
> understand how the above mentioned classes work.
>
> I also have to look at kislayer and kisimage again and see what they are
> exactly doing. kisimage probably provides some methods to load/save an
> image and kisimage is build out of several kislayers.

Nope, no loading or saving here, this has to stay independant of the actual 
storage implementation, Image here is only an in-core reprensentation.

>
> But I still don't know how the changed (dirty) tiles are rendered to
> the screen (e.g. a qwidget). Can you please tell me where I can find
> this 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.
_______________________________________________
kimageshop mailing list
kimageshop@mail.kde.org
http://mail.kde.org/mailman/listinfo/kimageshop