freak at codepimps.org
Mon Oct 13 11:20:48 CEST 2003
On October 13, 2003 03:53 am, Michael Thaler wrote:
> 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:
> 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,
In your document, you should really talk about QUANTUM, downscale and upscale.
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
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.
It appears that dirty and valid we're switched around in the code base, it is
supported, but using valid instead of dirty.
KisScopedLock, might be a bug here, don't know, haven't looked at the code in
Skipping some sections here:)
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
kis_global.h, upscale and downscale do more than nothing, again I refer you to
KisSelection, KisChannel, and KisMask too are paint devices.
Hey! I find KisGuide interesting :)
Why do you need these new functions?
More information about the kimageshop