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