From kde-kimageshop  Mon Aug 30 11:15:56 2004
From: Boudewijn Rempt <boud () valdyas ! org>
Date: Mon, 30 Aug 2004 11:15:56 +0000
To: kde-kimageshop
Subject: Re: koffice/krita
Message-Id: <200408301315.59380.boud () valdyas ! org>
X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=109386457624265
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============1332781299=="

--===============1332781299==
Content-Type: multipart/signed; boundary="nextPart6048466.jsUpMt5dSg";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart6048466.jsUpMt5dSg
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 30 August 2004 12:08, Cyrille Berger wrote:

> I was thinking about that, with the IterratorsRect (btw, is someone worki=
ng
> on them ?)=20

Casper already answered that.

> we can have a function that do a memcpy, this will hide the=20
> quantum to compositeop, which would have this prototype :
> compositeOp(KisIterratorsRect dst, KisIterratorsRect srcBegin,
> KisIterratorsRect srcEnd, QUANTUM opacity)

This sounds good: something we don't do enough is define the iterators and=
=20
then pass them on to the algorithm, the way iterators were intended to be=20
used, so this looks like a good step.

But there are a couple of problems with composition anyway, some linked to=
=20
rendering, others more general.

If we want to render separate channels, we'll have to composite pixel-by-pi=
xel=20
anyway.

I want to make a new colour model for selections, instead of using four=20
channels for what's effectively an alpha mask to a single colour -- and tha=
t=20
means I need to composite two colour models together.

>
> And for instance composite copyt would look like this :
> compositeCopy(KisIterratorsRect dst, KisIterratorsRect srcBegin,
> KisIterratorsRect srcEnd, QUANTUM opacity)
> {
>  if(opacity =3D=3D OPACITY_OPAQUE)
>  {
>   dst.memcpy( srcBegin, srcEnd);
>  }
>  else {
>   ...
>  }
> }
>
> This will hide the QUANTUM* and TileMgr to the strategy, which is somethi=
ng
> we were wanting to achieve.

Because of the problem with selections, I'm messing with the composition co=
de=20
anyway -- I'll keep this in mind, and I've just asked Casper for what he=20
already has in the matter of rect codes, so perhaps I can work something ou=
t.=20
It's blocking the work I want to do selections right now (although I could=
=20
also do the other selection tools first, and the select-by-colour dialog).

=2D-=20
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi

--nextPart6048466.jsUpMt5dSg
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBMwxvdaCcgCmN5d8RAlHfAJ931SJhIrq9S6OjMH94AY9rGE/2JQCfQFC0
QJnEVDGzZ+TN8osgqytbrZQ=
=WqIS
-----END PGP SIGNATURE-----

--nextPart6048466.jsUpMt5dSg--

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

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

--===============1332781299==--