krita tools

[Patrick Julien]

On October 3, 2003 12:37 pm, Boudewijn Rempt wrote:
> On Friday 03 October 2003 13:58, Patrick Julien wrote:
> > Well, you still have no line primitives in KisPainter.
>
> Okay... That would mean code similar to QPainter, I guess. I was hoping
> that the tools would take care of those, though.

Not quite, the code in QPainter probably just forwards to the native GUI 
library being used (XDrawRectangle in X, Rectangle in Windows and so on).  
Even if you had a look at the XFree86 code, that code can assumes a linear 
framebuffer, you have no such thing in Krita, hence the microtile data 
structure.

>
> > > Hm. This is getting deeper and deeper -- since you don't have time to
> > > implement your plan, is there a way to hack up some temporary
> > > scaffolding that would at least allow others to start with a
> > > more-or-less working set?
> >
> > Yes, you can use what is there, until the strategies are in, KisPainter
> > assumes an RGB color model.
>
> Well, RGB should suffice -- unless you mean there's no RGBA either. One
> would need alpha, I guess.

Yes and no, there is both RGB and RGBA.  However, it is dreadfully slow since 
values are not pre-multiplied.

I'm assuming a familiarity with design patterns here, but this is what I 
wanted to do:

1) Keep the color model in the paint device (KisImage, KisPaintDevice, 
KisLayer, etc) in the device itself (done).
2) Make a colorspace strategy
	This strategy would actually hold the entire colorspace in pre-multiplied 
form
3) The strategies are flyweights.
4) When creating a KisPainter, the KisPainter takes the color model id found 
in the paint device and gives it to the flyweight factory to get back a color 
space strategy.
5) The actual algorithms for the drawing are in KisPainter since they are the 
same, but pixels are composed using the strategy.

This means we can support all color models.
This means rendering is actually fast since all pixel results given a source, 
a destination, an alpha and a raster operation are know in advance.

>
> > Well, I can easily answer that question, nothing is finished.  I was
> > still working on the core.  I had mostly undo/redo done, and was working
> > on the rendering engine.  Porting to microtile was done, however, the
> > rendering system was still not complete.
>
> Hmmm. No design notes anywhere? Test code that shows that the strategy you
> planned would work after all?

:)  You are aware that this is volunteer work aren't you?  So, no, nothing 
like that is available.

Krita is already considerably faster than Krayon was, memory consumption for 
the image representation is down 85%.   Also, Krayon could only do 8 bit per 
channel, that restriction has also been lifted.  Also, using what was there, 
I'm not sure I had to courage to implement undo/redo.

>
> Anyway, I think I'll spend the weekend on trying to create a mental map of
> what's what in the krita code, and more specifically, what needs to be
> discarded.
>
> Did you tag krita cvs before you began your reworking? That would help me
> get a diff and then try to find out where you were headed.

Nope, maybe someone else did tho.  I started working on Krayon in June of 
2002.