From kde-kimageshop  Sat Oct 04 07:43:08 2003
From: Boudewijn Rempt <boud () valdyas ! org>
Date: Sat, 04 Oct 2003 07:43:08 +0000
To: kde-kimageshop
Subject: Re: krita tools
X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=106525345906329
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============49370478966990206=="


--===============49370478966990206==
Content-Type: multipart/signed;
  protocol="application/pgp-signature";
  micalg=pgp-sha1;
  boundary="Boundary-02=_Qonf/gtlCBGV7yM";
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


--Boundary-02=_Qonf/gtlCBGV7yM
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

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 b=
lit=20
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 ba=
ck
> 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 advanc=
e.
>

Okay, I'll get the GoF book from the shelves. Haven't looked in it for year=
s,=20
not after I got involved in a software project that had run riot with=20
patterns, completely losing sight of what was being designed. But this look=
s=20
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=20
work on a bit of code, I tend to accumulate a directory filled with notes,=
=20
code snippets and abortive UML diagrams (somehow I never finish those, but =
I=20
find that placing class names in boxes helps me understand a system).=20

>
> 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 image=
s=20
in layers and play with transparency and so on. That was fun. Anyway, I gue=
ss=20
that I can decide whether I feel confident enough to start adding code by=20
Sunday. I'll probably have some more questions for you soon.

=2D-=20
Boudewijn Rempt | http://www.valdyas.org/index2.html

--Boundary-02=_Qonf/gtlCBGV7yM
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQA/fnoQdaCcgCmN5d8RAppEAJ9hrw/+EovGFI6FSTW2DaueWikbrQCbBfDC
rq3ji4WYvGAED7JEzksE/hc=
=FJMY
-----END PGP SIGNATURE-----

--Boundary-02=_Qonf/gtlCBGV7yM--


--===============49370478966990206==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============49370478966990206==--