--===============1328917192==
Content-Type: multipart/signed; boundary="nextPart1475497.jbXMavY29R";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1475497.jbXMavY29R
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 09 September 2004 21:59, Boudewijn Rempt wrote:

Of course, I hadn't realized that we already sort of provide compositing pe=
r=20
channel with the COPY_RED, COPY_ALPHA composite ops. I'd need to add an=20
OVER_ALPHA and then my selection code will be a lot easier. Same with=20
applying the selection mask to the gradient and fill buffers.

However, whenever I see a pattern of constants like

OVER, OVER_RED, OVER_BLUE, OVER_GREEN, OVER_ALPHA
COPY, COPY_RED, COPY_XXX....

I think that there are two parameters mixed that shouldn't have been mixed.=
 So=20
it would still be a good thing to pass a vector of channels-to-be-composite=
d=20
to the bitBlt methods, and get rid of the XXX_RED, XXX_GREEN, XXX_XXX=20
constants (and separate implementations). Need to find a way to measure=20
performance impact, though.

Perhaps a timed loop that does a large number of compositions, reachable vi=
a a=20
debug menu option Krita.


=2D-=20
Boudewijn Rempt | "Geef mij maar zuurtjes."
http://www.valdyas.org/fading/index.cgi

--nextPart1475497.jbXMavY29R
Content-Type: application/pgp-signature

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

iD8DBQBBRVCWdaCcgCmN5d8RAkk8AJ42bNWy5pXEZCp1ZE14itPGg4fCuwCgm7he
bCdprelomL7YJK+TP4/v8Do=
=8aW8
-----END PGP SIGNATURE-----

--nextPart1475497.jbXMavY29R--


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

--===============1328917192==--