--===============0280374387==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	micalg=pgp-sha1; boundary="Boundary-02=_oV8h/9OovKKRz8J";
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


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

On Saturday 11 October 2003 02:18, Patrick Julien wrote:

> Actually, again, the pointer is already set to the same address, i.e. the
> image we're initialize with pd -> data, don't forget you newup pd -> data,
> KisPixelData dtor will delete it correctly, but this makes your intent
> harder to understand.  It doesn't put them back after all, it's exactly t=
he
> same buffer you passed in to QImage in the constructor call...

I was wondering about that, because when I remove a similar line from code =
I=20
posted earlier, nothing seems to happen -- the QImage that=20
QPixmap.convertToImage() returns is a different thing than the QImage I=20
started out with, it seems.

Anyway, what I wanted was to have a KisPaintDevice subclass (and I choose=20
KisLayer after an abortive attempt at a KisDab) that I can use to give to t=
he=20
KisPainter bitBlt methods, for instance:

void bitBlt(Q_INT32 dx, Q_INT32 dy,=20
            CompositeOp op, KisPaintDeviceSP src,
            QUANTUM opacity,=20
            Q_INT32 sx =3D 0, Q_INT32 sy =3D 0,=20
            Q_INT32 sw =3D -1, Q_INT32 sh =3D -1);

That way the existing bitblt functions can handle the various kinds of=20
compositing and opacities, and also the undo/redo. That's necessary because=
=20
every kind of brush or penwork should be possible with every kind of=20
compositing. Having the compositing/tile walking code in one place seemed=20
like a good idea to me.

So somewhere I need to create that layer. Perhaps the order should be:

determine the rect that is painted upon
create a transparent pixmap
do the brushwork
get the image from the pixmap
create the layer with that image
bitBlt the layer onto the KisPaintDevice we where painting on.

My first take was to grab the rect from the KisPaintDevice with all the=20
existing pixels in, convert that to a QPixmap, draw on it, and push it back=
=2E=20
I've got that working nicely now, except that if I create a transparent lay=
er=20
and draw on that, things go horribly wrong. I have a nagging suspicion that=
=20
QPixmap is a bad choice for a transparent paint device.

Maybe I should drop the idea of hijacking QPainter, and investigate some ot=
her=20
lib that offers graphics primitives, or even (shudder!) try to code them=20
myself. I was hoping, though, that getting most of the back to working woul=
d=20
entice other, better, hackers to Krita and get them to do that code :-).

I'll have one last attempt this morning at getting the temporary layer idea=
=20
working; if that fails I'll just implement temporary code following the old=
=20
scheme for all tools and get those tools working again.

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

--Boundary-02=_oV8h/9OovKKRz8J
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA/h8VodaCcgCmN5d8RAj4pAJ9kxmFcK+wlTqNIK2ILwS0kqNbPeQCgliHZ
pmPKFWvTSAlwHUS7bRjViYI=
=Jwgu
-----END PGP SIGNATURE-----

--Boundary-02=_oV8h/9OovKKRz8J--


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

--===============0280374387==--