krita overview

[Patrick Julien]

On October 13, 2003 03:53 am, Michael Thaler wrote:
> Hi,
>
> I spend a lot of time at the weekend to read through krita's code. I
> wrote a pretty long and detailed overview about various krita classes
> and their functions. It is by no means complete and I did only try to
> understand the most basic krita classes and some things I did not
> understand at all, but nevertheless this might actually be usefull.
> You can find my overview here:
>
> http://www.physik.tu-muenchen.de/~mthaler/krita_overview.txt
>
> I would really like to comment the code itself and then create a nice
> documentation using doxygen. This will help me and other people to
> understand the code more easily.
>
> For now I think about commenting the classes and member functions in
> the header files. Should I just sent the header files with the
> comments to this list?
>
> I would also like to code the missing parts to mark the tiles as
> clean/dirty. This is probably not too hard to do and it is definitely
> needed to code freehand tools.
>
> I still want to make paintworks working with KisLayer, KisPainter and
> all other necessary classes. paintworks already has a nice set of
> filters and if I get them working with KisLayer and KisPainter it will
> probably be easy to port them to krita. I think this is also good for
> me to get some more experience with painting apps and to learn some
> more advanced C++ stuff (And I also want to read the Gang of Four book
> at some point;-).
>
> Take care,
> Michael

Some corrections...

In your document, you should really talk about QUANTUM, downscale and upscale.

KisPixelData...
	1) The owner flag indicates if the KisPixelData owns the the actual memory 
pointer to by the QUANTUM array.  If so, delete[] gets called on it at 
destruction time.
	2) stride is what you have to add to get to the next line, sometimes, even if 
your KisPixelData is smaller, we have to fetch a bigger block of memory, 
hence stride takes that into account, width does not.

	So base + stride = line 2, but base + width might be line 2 or might be 
outside the memory region you requested, but still inside the paint device.

KisTileCacheInterface, also used to help swapping, every tile would actually 
put it's data in here for easy maintance, when you lock, we actually try to 
get the data from here first, then from the swap interface.

KisTile

	It appears that dirty and valid we're switched around in the code base, it is 
supported, but using valid instead of dirty.

KisTileMgr
	KisScopedLock, might be a bug here, don't know, haven't looked at the code in 
a while.

KisRenderInterface
	What Java?

Skipping some sections here:)

KisPaintDevice
	KisImageSP returned is actually the owning image of this device, KisImage is 
itself a paint device.

	Downscale is very important!  See my previous mails on this list.

	The read and write methods should probably be moved here, you know I will do 
something about that, just maybe :)


KisStrategyColorSpace, it's actually hopes to be more than that, see previous 
mails on this list.

KisStrategyColorSpaceRGB, we render tiles 4 at a time, otherwise, we slow down 
X too much, bliting tiles in chunks of 64x64 instead 64*64x64*64 get too be 
too slow

kis_global.h, upscale and downscale do more than nothing, again I refer you to 
the list.

KisSelection, KisChannel, and KisMask too are paint devices. 

Hey!  I find KisGuide interesting :)

Why do you need these new functions?