Comment 2 for bug 1034391

Some notes from smspillaz on how it might be implemented, for whoever (not smspillaz) would be doing the implementation:

12:33:10 <aquarius> How possible would it be for compiz (or possibly something else in the graphics stack) to keep a picture of an app's window around for a bit after that app crashes?
12:33:35 <smspillaz> perfectly possible
12:33:55 <smspillaz> well, compiz would be able to
12:34:15 <smspillaz> it just might get a bit weird though because you're managing a window that doesn't exist
12:34:19 <aquarius> so, if an app crashes (and thus the process exits), compiz could continue to show its window as though it had not crashed (although obviously that window would not be interactive)
12:34:24 <smspillaz> so I can forsee running into lots of really small problems
12:34:38 <aquarius> yeah, this is why I'm asking you about it :0
12:34:42 <aquarius> I had this idea, you see:
12:34:43 <smspillaz> it would be able to show its window, I don't think we'd be able to handle things like raising it and lowering it from it scurrent position in the stack sanely
12:34:56 <smspillaz> it would have to stay at the top
12:35:02 <aquarius> when an app crashes, apport kicks in and five seconds later you get the apport crash dialog
12:35:37 <aquarius> what I'd *like* to happen is that an app crashes, its window goes grey (or maybe, I don't know, red or something) and then apport draws the crash dialog into the crashed window
12:35:54 <smspillaz> oh ok, the drawing into the crashed window bit is where you're going to run into trouble
12:36:11 <aquarius> so the crash dialog isn't saying "that app that was running five seconds ago crashed", and it's not even saying "that app over there crashed", it's saying "this app right here crashed".
12:36:22 <smspillaz> right I see what you mean
12:36:57 <smspillaz> you'd have to have some kind of apport plugin for compiz to handle that case though
12:37:07 <aquarius> I had this thought: app crashes, compiz says "aha, a crashed app, I will continue to display its window for a bit", apport starts up, apport creates its *own* window at the same size and position, compiz says "here is the texture from the crashed app", apport displays that, compiz forgets about the texture
12:37:33 <aquarius> so there's a brief time window (in between app segv and apport creating a window) in whcih compiz is managing a window for no app, but it's short
12:37:47 <aquarius> and then after that it's all apport and compiz can forget about it
12:37:58 <smspillaz> right, so its doable but there are three parts about this that are decidedly nontrivial
12:39:18 <smspillaz> okay so the first one is that there's a race between getting the notification that the application crashed as opposed to the window recieving a DestroyNotify from the server
12:39:31 <smspillaz> if the latter happens first compiz will just play the close animation
12:39:49 <smspillaz> we'd need some kind of synchronization there
12:40:14 <smspillaz> the server doesn't tell you why a window was destroyed
12:40:19 <smspillaz> it just tells you that its destroyed
12:41:15 <smspillaz> I mean what you could do
12:42:00 <smspillaz> is have a plugin that specifically inhibits all close animations until we check with apport as to why the window was destroyed, and hopefully by then it would have known by way of kernel events why the application died
12:42:17 <smspillaz> this of course requires matching process ID's to windows which is another whole can of worms
12:42:32 <smspillaz> because there's no facility for doing that in the protocol
12:42:52 <smspillaz> so you'd only get it from applications that are EWMH compliant (which is probably about 99%)
12:44:51 <smspillaz> although most applications will export that data on their windows now
12:45:33 <smspillaz> problem 2 is "keeping the window around" - you can keep the window around, but its difficult to do so in a sane manner unless you want more stacking bugs
12:46:05 <smspillaz> you have the same problem when animating out minimized and closed windows, we "estimate" where they need to go in the stack and put them there when painting them
12:46:16 <smspillaz> but you can't for example raise or lower a destroyed or unmapped window
12:46:36 <smspillaz> so you'd get some weirdness there but hopefully it won't be too long
12:46:37 <aquarius> because compiz doesn't actually raise and lower things, it just passes on mouse clicks and then the app itself says "raise me" and compiz responds... but now there's no app to receive the clicks?
12:46:50 <smspillaz> actually compiz raises and lowers things server side
12:47:11 <smspillaz> it captures the click on the window and then issues the raise request (which is how you're supposed to do it)
12:47:30 <aquarius> yeah, having a window unable to change its position in the stack would be odd and weird, but ideally it would be seconds at most before apport appears and the "fake window" becomes a real proper window again
12:48:29 <smspillaz> I suppose what we could do is throw up an input only window when we know the actual application is dead and paint the "crashed" window in the same part of the stack as the input only window
12:48:42 <smspillaz> or a real window at that
12:48:48 <smspillaz> there are ways to handle this case
12:48:56 <smspillaz> its just tricky
12:49:08 <smspillaz> and then I guess the third is getting the window texture into apport
12:49:40 <aquarius> the important part is that the window doesn't disappear and then reappear a second later; it just greys out. Whether that's actually because the same window hangs around or because a new window is created which looks identical and is atomically swapped for the previous one doesn't matter, of course
12:51:12 <smspillaz> I think you could probably grab the window texture, given that most texture from pixmap implementations involve a copy from pixmap memory to texture memory
12:51:19 <smspillaz> it would just be hard