[12:03] mlankhorst, hi :), are there (precise) packages for wine 1.6.1 yet? [16:37] ricotz: erm scott ritchie does those [16:45] mlankhorst, ok, thanks, since you are involved too, i was hoping you had uploaded it somewhere already -- haven't found it on launchpad though [20:31] i've got a question about RetainPermanent and the various atoms used to signal the existence of such on the root window pixmap [20:33] first: there's a bunch of different ones: XSETROOT, XROOTPMAP, ESETROOT_PIXMAP_ID, _XROOTPMAP_ID... any more? [20:34] second: how do these pixmaps get freed? if i set and change the background image using one of these tools, it's going to keep allocating new RetainPermanent pixmaps. how are they supposed to get deallocated? [20:36] RAOF: in my searching on this topic i saw you discussing RetainPermanent in relation to unity-greeter. can you tell me anything about this stuff? i'm hacking on lightdm-gtk-greeter for xubuntu [21:01] it looks like unity-greeter defines RetainPermanent but doesn't use it. so how does the wallpaper handoff happen between unity-greeter -> compiz? [21:02] ali1234: no idea, magic? :> [21:02] well all this RetainPermanent stuff sure feels like magic [21:03] I guess until compiz starts compositing the old image will exist [21:03] because nothing new has been drawn to it yet [21:04] the problem we have is xfwm starts compositing with a empty grey buffer, and there's a delay before the app that draws the wallpaper starts up [21:04] xfwm can read the RetainPermanent background at startup to avoid this, but the whole thing seems incredibly bad with magic atoms and unmanaged buffers... [21:17] I think you can just read out the uncomposited buffer before starting to composite [21:17] or at least delay drawing until you have a background [21:18] but I haven't put much thought since I mstly worry about driver issues ;) [21:19] speaking of driver issues, why does nouveau corrupt the hell out of the display when using RetainPermanent pixmaps? [21:20] "oh, you wanted your wallpaper? here's some windows that were on your screen earlier today" [21:22] i think "read out the uncomposited buffer" is what compiz does, that's probably going to be our best option [21:22] I guess it uses random vram memory with nothing drawn to it yet [21:22] which happens to match window contents in some cases