xfwm4 compositor and the root pixmap.

[Alistair Buxton]

On 27 November 2013 10:33, Olivier Fourdan <fourdan at gmail.com> wrote:
> As to why I disabled the root pixmap property in the build, that's
> because some app will kill the owner of the previous pixmap. If that
> happens to be the window manager, too bad.

This is only half-way correct. There is a standard for how to set the
background pixmap and when to kill the pixmap owner, but neither xfwm4
nor xfdesktop currently implement it correctly. This is why they both
crash so much if you enable the background handling code in both of
them at the same time - they fight each other for control. Since one
of them only ever reads the pixmap and the other only ever writes it,
there is no reason why they shouldn't work correctly together.

The root atom pixmap can never be owned by xfwm4, so xfwm4 can never
get directly killed by enabling this code. This problem does however
affect xfdesktop, where the background code is enabled by default. I'm
going to fix that after I've fixed xfwm4.



So, after another day of head scratching I realised that making a copy
of the pixmap was uneccessary. What I really needed to do was make
sure that xfwm4 does not free pixmaps it does not own. I then found
out that the solid background pixmap was also unnecessary - there is
an XRender utility function for doing this job. So in the end I was
able to do the same thing while making the code shorter. See the
commit messages for details:

https://github.com/ali1234/xfwm4/commits/bgfix2






-- 
Alistair Buxton
a.j.buxton at gmail.com