--===============1916169645==
Content-Type: multipart/signed;
  boundary="nextPart28178244.SXejTVTEdc";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart28178244.SXejTVTEdc
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Thursday 27 January 2011 18:22:24 Thomas L=FCbking wrote:
> Am 27.01.2011, 14:19 Uhr, schrieb Hugo Pereira Da Costa
>=20
> <hugo@oxygen-icons.org>:
> > Interesting.
> >=20
> > I was following a different path on my side, namely pass the pixmaps the
> > same way as icons are passed to the _NET_WM_ICON. (that is: the entire
> > pixmap data are passed, and not the X11 handle).
>=20
> Bespin shares pixmaps for client and deco this way, just have a look - you
> know the code ;-)
> (there's even a simplifying class, but I pass XRender Pictures, Pixmaps
> are however no different)
>=20
> The icon way is _horribly_ slow, but you're very right about the tricky
> part which is the lifetime of the
> Pixmap - if you just create it from a client, it will be gone with the
> client process, so either
> _every_ client would have to provide it (shared between clients of the
> same process) or kwin
> has to create and keep the pixmaps and the client gets the handle and
> creates the pixmap on it.
> This would however not survive a kwin restart.
Given that we don't expect the shadows to be changed often (once in the=20
lifetime) I think the slowness is no problem. Passing the handle seems=20
dangerous to me and the advantage of the damage events is rather low.=20
Nevertheless it might be a good solution in case we want different shadows =
per=20
window.
>=20
> Afaik the only way to directly assign a pixmap to a (root) window is
> XSetWindowBackgroundPixmap,
> but that cannot be used since it provides only one pixmap (ok, one could
> handle this like a texture set)
> and is (in our case) the visible rootwindow background (what is the
> wallpaper for desktopwindow free
> sessions and also used by clients like conky for faked translucency ->
> we'll get bug reports for abusing
> this =3D)
Yes, definately not a good idea to paint on the root window.
>=20
> Altogether i'm not really convinced about clients passing shadow pixmaps
> onto the root window (that's
> free space, everybody can -accidentally- kill those pixmaps anytime) and
> still believe that it should be
> enough for the clients to share some lightmodel parameters (direction,
> strength, maybe fuzzyness) and
> keep the shadow generation and pixmaps/textures in kwin which can then
> perform presence/sanity checks
> and use fallbacks/defaults instead of running into BadPixmap errors...
I don't know if such generic ways would fit the needs of the toolkits. Hugo=
=20
and Craig: please comment on what suits your needs better.

Cheers
Martin

--nextPart28178244.SXejTVTEdc
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

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

iJwEAAECAAYFAk1Bz9gACgkQ/umpWjNT6CIxZQP+LNoe1VAdGC2Gcp9SKnI5k7lY
lyk0ZDzPsY4thbAvr47SpD2pXUysTuMVmGc+M0EK335GbBUDk/HkOs0fgyzUZfMF
G9SgYuWxe9yorTJCbcQdR8SzwM4/ZmGqMJNCBwhcoFbLJaCYloI+Ptd/jnCqVdk8
QVCH5Vm9T4M3JBfFVZE=
=D30/
-----END PGP SIGNATURE-----

--nextPart28178244.SXejTVTEdc--

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

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

--===============1916169645==--