[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: How does krita render tiles to the screen?
From:       Michael Thaler <michael.thaler () ph ! tum ! de>
Date:       2003-10-11 9:01:43
[Download RAW message or body]

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.

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?

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

Cheers,
Michael
-- 
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.

_______________________________________________
kimageshop mailing list
kimageshop@mail.kde.org
http://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]