Hi, I hacked up a quick tool last night which makes viewing the server side stacking and geometry a lot easier than trying to parse the output of xwininfo -root -tree. It's called "stack inspector" and can be found at lp:~smspillaz/+junk/stackinspector.
There are two included utilities. The first, stackprint, prints out a slightly more readable stacking order than xwininfo -root -tree from top to bottom, which includes the following data: * _NET_CLIENT_LIST * _NET_CLIENT_LIST_STACKING All top-level children of the root window from top to bottom, with the following information * Whether or not that window is a parent of some other managed window (eg, in _NET_CLIENT_LIST) * The window type and state * Override redirect and map state * Geometry * Shape extents The second tool is a more graphical implementation of this. Here's a screenshot: http://www.ucc.asn.au/~smspillaz/compiz/screens/stack_inspector.png It is a tool that displays the stacking order top-to-bottom in a tree view as well as a graphical representation that is generated on the fly by cairo and xcomposite working together of the server side stacking order. There's filters to show override redirect windows, unmapped windows, input-only ones and the viewer itself. Also, when you select any particular item in the tree view, it the viewer window will only paint everything up to that window and no more, so you can examine levels of the stack to try and figure out if there's something weird going on (like toplevels over unmapped override redirect windows). Also, you can see if the stack order on the server side and client side are clearly out of sync by comparing the image to the desktop. The second tool requires the "mm" bindings to cairo, gdk and gtk Q&A: Q: Why is there all this corruption on the viewer window. Why are there no decorations A: The frame window that we reparent other windows into is an InputOutput window that doesn't have its backing area cleared since we never paint it in compiz. When we redirect toplevel windows and draw them, this lack of clearing is evident when you paint the window. Unity itself is going to appear as garbage since all of its windows are InputOutput windows which we inhibit painting of and we paint the nux widgets on screen directly inside the compositor. That won't work inside of here. Q: Why did you use GtkMM. I hate you. A: Because I can't be bothered writing tons of boilerplate and I like C ++. That's why. Q: Why is it slow? A: It's essentially super-synchronous. In order to avoid stacking bugs inside of the stacking debugger, it re-queries the X server for the entire window tree, relevant properties and other data every single time something changes server side and this is really slow. On another note, I've found doing the compositing with cairo to be surprisingly faster than I thought, even at large resolutions Q: Why does it slow down performance in compiz too? A: Because it uses server grabs. That's only going to apply when this is running Q: Does this mean my stacking is fixed? A: No, I still need to figure out where the rest of the race conditions are. This tool will save my brain though. Q: What do you plan to do with this in the future A: We can probably use this as a test harness for the new stacking code to compare what's on the server with what the stacking code thinks the stack is to nip any problems in the bud. Also, I think it should be possible to record what's going on on a user's system, so if they have a reproducible bug they can just send us the log and this tool can play it back (albeit, with no pixmaps, only puke-colored rectangles). I also want to make it handle stuff like damage events so you have realtime thumbnails though I think that's more of a distraction than a help. -- Sam Spilsbury _______________________________________________ Mailing list: https://launchpad.net/~ayatana-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~ayatana-dev More help : https://help.launchpad.net/ListHelp
