From kde-kimageshop  Tue Oct 28 20:22:16 2003
From: Boudewijn Rempt <boud () valdyas ! org>
Date: Tue, 28 Oct 2003 20:22:16 +0000
To: kde-kimageshop
Subject: core/color_strategy
X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=106737348618688
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============0261265281=="


--===============0261265281==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	micalg=pgp-sha1; boundary="Boundary-02=_8/sn/f+91M2VAz2";
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


--Boundary-02=_8/sn/f+91M2VAz2
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

Hi,

Just updated and got the move to core/color_strategy -- now I see what you=
=20
meant by flyweights. I thought you wanted a flyweight object for every colo=
r,=20
so pixels can point to those colors, or something like that. Because I=20
thought that the essence of flyweight was that there were many of them, and=
 I=20
guess we'll never have more than a handful of color models.

Anyway -- this is very nice. I've made a start adding composite methods to=
=20
every the color models. Is that okay, or were you working on that?=20

I'm currently having a signature like:


virtual void composite(QUANTUM *src,=20
   QUANTUM *dst, Q_INT32 opacity, CompositeOp op);

Where src and dst point to just enough bytes to define a pixel.=20

I've looked at putting a koColor in and getting a new koColor back -- which=
=20
somehow seems neater to me, more encapsulated. But that would be more costl=
y,=20
since every pixel needs to be converted to a koColor then, and even an arra=
y=20
of flyweights for every color in the picture wouldn't help Krita from=20
becoming memory-hungry.=20

And I've played with passing pointers to the entire scanline, or all the by=
tes=20
in the tile, together with the length of that block, but while that would b=
e=20
very efficient for copy operations, I thought it rather ugly in design, and=
=20
anyway, optimisations can always be done later.

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

--Boundary-02=_8/sn/f+91M2VAz2
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA/ns/8daCcgCmN5d8RAsUwAKDu9WRvJFGQJAnPhGPCKBPt8B6g4ACgzQ+N
Wgj7Tv+Czu1rK+88cn8W9bI=
=NlYu
-----END PGP SIGNATURE-----

--Boundary-02=_8/sn/f+91M2VAz2--


--===============0261265281==
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

--===============0261265281==--