freak at codepimps.org
Fri Oct 3 19:33:21 CEST 2003
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
> > > 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
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
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
> 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
More information about the kimageshop