[Ayatana-dev] Introducing Stack Inspector

[Sam Spilsbury <smspillaz@xxxxxxxxx>]

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