© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
So after massive amounts of investigation this is what I came up with:
1. lightdm-gtk-greeter uses RetainPermanent pixmaps to set the background. What this means is that it opens a second connection to the X server, allocates the pixmap as RetainPermanent, pushes it into the root window, and then closes the connection. Usually when a client disconnects all resources get deallocated, but RetainPermanent prevents this, so the pixmap stays.
This is a widely used technique, but lightdm-gtk-greeter does not implement it in the standard way. usually when you do this you also set atoms pointing at the pixmap so that other programs can later change or deallocate those pixmaps - otherwise they just get leaked. lightdm-gtk-greeter does not do this. It should.
2. Xfwm4 starts up in compositing mode. All the composited windows are drawn into a buffer, then the buffer is drawn to the root window. This means that even if there's no windows on screen, the buffer will still draw over whatever pixmap is in the root window. At startup, Xfwm4 fills it's buffer with solid grey, so that's what you see. Xfwm4 has code to read out the root pixmap set using RetainPermanent, but again, it seems to be a none standard implementation which uses wrong atom names to get the pixmap addresses. This should also be fixed. Also this code is usually disabled as it is used in "monitoring" mode, when xfwm4 will constantly check if the root pixmap changed and copy the new one to it's composite buffer. We don't need to do that because xfdesktop handles our background. We only need to copy once, at startup, to fill the gap.
References:
http://
https:/
https:/