[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: krita tools
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2003-10-04 7:43:08
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 04 October 2003 00:33, Patrick Julien wrote:
>
> 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.
>

There are bitblt functions that look useful -- if I make a brush mask and blit 
that on KisPainter, that should work, shouldn't it.

>
> 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.
>

Okay, I'll get the GoF book from the shelves. Haven't looked in it for years, 
not after I got involved in a software project that had run riot with 
patterns, completely losing sight of what was being designed. But this looks 
useful.

> >
> > 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.

:-). I know -- my interest is purely on a volunteer basis, too... But when I 
work on a bit of code, I tend to accumulate a directory filled with notes, 
code snippets and abortive UML diagrams (somehow I never finish those, but I 
find that placing class names in boxes helps me understand a system). 

>
> 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.
>

Well, I was impressed to see the speed with which I could combine two images 
in layers and play with transparency and so on. That was fun. Anyway, I guess 
that I can decide whether I feel confident enough to start adding code by 
Sunday. I'll probably have some more questions for you soon.

-- 
Boudewijn Rempt | http://www.valdyas.org/index2.html

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kimageshop mailing list
kimageshop@mail.kde.org
http://mail.kde.org/mailman/listinfo/kimageshop


[prev in list] [next in list] [prev in thread] [next in thread]