xfwm4 compositor and the root pixmap.

[Alistair Buxton]

After a lot of head scratching this is what I came up with:

https://github.com/ali1234/xfwm4/commit/27b4d152d84868ed06b424d4cfedfcbab08f73c8

This fixes the MONITOR_ROOT_PIXMAP code so it is safe and works in an
expected way.

Currently xfwm4 trusts that the pixmap it finds on the root atoms will
stay around (which it might not) and that nothing else will ever try
to draw into it (which they might). Specifically, xfdesktop does both
these things, and there is no guarantee any other software won't mess
with it. I fix this by making a private copy of the root pixmap.

Since there is now a private copy of the pixmap, there's no need to
handle when the atoms get deleted, as the private copy is still valid.
This ensures we keep the desktop wallpaper even during xfdesktop
restart.

Finally, this code orders a screen redraw when the background changes.
Without this you only see the new background when you move a window
around (when xfdesktop is not running of course).

So, as the patch says, there's three ways this can be used:

1. Turn it off completely, in which case the code behaves exactly the
same as it does now.
2. Enable it completely, in which case you can go from greeter to
xfdesktop without any background flicker, and you can restart
xfdesktop without any flicker, and you can even not use xfdesktop at
all and set the background with xli or hsetroot if you want (I believe
that was the original intended purpose of this code.)
3. Only copy the background at startup and ignore any change events,
which gives you the seamless greeter->xfdesktop transition, without
the overhead of redrawing a background you never see because xfdesktop
is handling it. You'll still get flicker if xfdesktop crashes after
you have changed the wallpaper for this session, but that's quite a
corner case.

There are still a few problems in the way xfdesktop handles the
background: it sets ESETROOT, but according to the spec it should not
do this - only RetainPermanent clients should set it, so that they can
later be killed. xfdesktop setting this atom makes it liable to be
killed by other random software. It should also free up any existing
background pixmaps found in ESETROOT when it starts up, to avoid
client connection and memory leaks.


On 25 November 2013 18:40, Alistair Buxton <a.j.buxton at gmail.com> wrote:
> With compositing window manager the real root window is never visible
> because of the offscreen buffer, so the compositor always has to
> handle the background.
>
>
> On 25 November 2013 09:10, Nick Schermer <nick at xfce.org> wrote:
>> Haven't tried anything of this, but what if xfwm4 does not touch the bg
>> pixmap at all? Is that even possible.
>>
>> IIRC X preserves the pixmap as well, so why have xfwm4 handle this?
>>
>> Nick
>>
>>
>> On Fri, Nov 22, 2013 at 9:47 PM, Alistair Buxton <a.j.buxton at gmail.com>
>> wrote:
>>>
>>> When using compositing, xfwm4 fills it's background with solid grey,
>>> and then drawing the user's wallpaper is left up to xfdesktop. That's
>>> all fine, except that there's a few seconds after xfwm4 starts and
>>> before xfdesktop starts where you can see the ugly grey. If your X11
>>> login screen already set the user's wallpaper this looks bad, as it
>>> goes grey, and then goes back to the correct image.
>>>
>>> Xfwm4 has some code inside MONITOR_ROOT_PIXMAP defines which is not
>>> normally enabled. This does two things: it copies any pixmap it finds
>>> at startup, and then it constantly monitors the root for changes.
>>>
>>> I think it would be a good idea to always copy the root pixmap on
>>> startup, to avoid the few seconds of grey, even if MONITOR_ROOT_PIXMAP
>>> is not defined. eg:
>>>
>>>
>>> https://github.com/ali1234/xfwm4/commit/b7baa7aa60cdb80759e0872d0ab5a7cb59ec5c10
>>>
>>> Also, the different atoms used by various software to control the
>>> RetainPermanent root pixmaps has many different possible names. Does
>>> it make sense to add these? As well as XROOTPMAP and XSETROOT it
>>> already checks, there is also _XROOTPMAP_ID and ESETROOT_PMAP_ID which
>>> all have exactly the same meaning as far as I can tell. It seems like
>>> it would be easy to add these, at least for the initial copy.
>>>
>>> What do you think about this?
>>>
>>> --
>>> Alistair Buxton
>>> a.j.buxton at gmail.com
>>> _______________________________________________
>>> Xfce4-dev mailing list
>>> Xfce4-dev at xfce.org
>>> https://mail.xfce.org/mailman/listinfo/xfce4-dev
>>
>>
>>
>> _______________________________________________
>> Xfce4-dev mailing list
>> Xfce4-dev at xfce.org
>> https://mail.xfce.org/mailman/listinfo/xfce4-dev
>
>
>
> --
> Alistair Buxton
> a.j.buxton at gmail.com



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