Mark McLoughlin

I finally got around to committing some changes to GConf which Lorenzo Colitti’s analysis of GNOME startup time showed would make a considerable improvement to login time. More details here.

The most frustrating part of this is just how difficult it is to get decent, reproducible figures of login time to show the improvements.

I first tried using bootchart to reproduce the results as Lorenzo had done. I hacked up a script to run gdm on a test machine, automatically login as a test user and get a bootchart of the time between gdm starting and the panel finishing loading the applets. I did a number of runs for each of my test cases – unmodified GConf, unmerged tree; unmodified GConf, merged tree; patched GConf, merged tree.

Unmodified	Merged Tree	Merged Tree, Split Translations

You can see improvements, just as Lorenzo predicted, but annoyingly each run of bootchart varied wildly from others, so you can’t really be sure exactly what difference you’ve made.

Next, I tried a much more low-tech approach. I wrote a script to record a timestamp in a text file in /tmp and ran that script from xinitrc and from the panel (once it had finished loading applets). By making the script reboot once it had recorded the second timestamp, and configuring GDM to login automatically, I could walk away from the machine and let it record a bunch of timings rather than sit there and watch it reboot.

Disappointingly, these results varied quite a bit too. But, by discarding obvious anomalies (note my ignorance of statistical methods) and taking an average, I got:

• Unmodified GConf – 14.382s
• Unmodified GConf; merged tree – 13.978s
• Patched GConf; merged tree – 11.086s

That shows a ~20% improvement in login time, which is certainly promising.

I’m always a tad shocked when Red Hat Magazine comes out every month with some genuinely interesting and useful articles. Really nice to see Integrating your applications into the desktop, Part 1 from Zana this month, for example.

Maybe I’m dumb and I missed it, but I hadn’t seen Lorenzo Colitti’s analysis of GNOME startup time mentioned anywhere. Well worth reading.

xscope is so damn useful.

Here’s a patch to make it support the SHAPE extension. It’d be really good to get this thing into freedesktop.org and so people can hack on it to make it sane.

I should try out Soeren’s gtk xscope wrapper.

I’m not sure what’s the best way to build the thing, but if you check it out from keithp’s CVS and do:

$> imake -I/cvs/xorg/config/cf
$> make

then it seems to build just fine if you remove the malloc() prototype in common.c. Of course, if you have a space between the -I and the path to the xorg build on the imake command line, then you could find yourself spending a long time trying to figure out wtf is wrong.

Oh, yeah, one final tip. xscope is a proxy Xserver. So, when you connect your app to xscope, Xlib goes looking in ~/.Xauthority for an xauth cookie to use when authenticating. Because xscope has a different display number from the parent display, though, you need to use xauth to setup the cookie for this display number too. So, assuming the parent display is :0 and xscope is :1, you can do:

$> xauth list | grep '/unix:0' | while read display proto cookie; do xauth add ${display%0}1 $proto $cookie; done

Caolán and I spent a while being generally childish (like changing the web page on the Sun Rays from sun.com to redhat.com etc.) at the Sun booth at LinuxTag. Much chuckles was had, though, when we saw this:

Marketing people are silly. Vino should clearly have a bigger box than piffling little OpenOffice.org 🙂

Truly bizarre and somewhat disturbing 🙂 I feel like I should become an Internet recluse now or something …

Anyone that uses Xnest will have gotten annoyed when it gets confused about the modifier state and it thinks e.g. Alt is pressed when its clearly not. Given that the bug has been around forever, it was seriously gratifying to fix it last week.

And before anyone says “Xnest sucks; use Xephr“, this is actually a bug in Xephr too … 🙂

I’ve been been doing a lot of work changing Sabayon around so that the list of changes you make in the prototype session aren’t displayed within the prototype session itself. I think it makes a lot more sense.

Lots of work still remains to get the changes list someway usable given the limited space, though. I may have to get jrb to rescue me.

This month’s Red Hat Magazine has a really nice article on Sabayon from Zana.

The details of behind input focus and X/GTK+ have always confused the
hell out of me. Its all fine and dandy when you only have to think
about GTK+ focus, but whenever I had to think about the interaction
between GTK+, the window manager and what’s actually happening at the
Xlib/Xserver level, by brain used to go to mush. I’d barely figure
out the bits neccessary to fix whatever bug I was up against and
promptly forget it all again five minutes later.

Well, this morning I have to get focus handling working with Xnest
embedded in a GTK+ window. So, I figure I’m really going to have to
understand it this time. Here’s some of the details:

• In order for any X window to receive events of a certain type,
  you must call XSelectInput() on that window with the
  appropriate event mask.
• When a key event is generated, the Xserver tries to find a
  client and window to deliver the event to. It starts with the
  window which contains the pointer and recurses up through its
  ancestors until it finds a window with that event selected.
• X has the notion of “the keyboard focus window”. This is set
  using XSetInputFocus(). When a key event is generated,
  the event is propopagated as normal if the focus window contains
  the pointer, but propogation stops at the focus window. If the
  focus window doesn’t contain the pointer, the event is
  delivered directly to the focus window.
• What’s important here is this has nothing to do with GTK+
  keyboard focus. Its more about which toplevel window is
  currently focused by the window manager, rather than which
  widget is focused within the application. The XEmbed
  spec more or less redefines this as the window’s “activation
  state” – i.e. if a toplevel or its descendants is the current
  keyboard focus window then the toplevel is said to be active.
• None of this really reflects the way modern desktops and
  toolkits work. What happens in reality is that applications
  never focus themselves (i.e. XSetInputFocus()) unless
  the window manager tells it to using the WM_TAKE_FOCUS ICCCM
  ClientMessage.
• On receipt of this message GTK+ makes a 1 pixel square window,
  located just outside the visible area of the toplevel
  window, be the keyboard focus window. That causes all
  KeyPresses to always go straight to this window (the window
  doesn’t have any descendants which can contain the pointer).
• When this window receives an X KeyPress event, GTK+ then
  generates a GTK key press event (with the toplevel as the
  target window) and puts that on the GTK event queue.
• At this point the event is entirely in the hands of GTK+. X
  has wiped its hands of the whole affair.
• Each toplevel GtkWindow knows which widget within the window
  is currently focused. All the toplevel now needs to do is
  send that event onto the currently focused widget.

One last little interesting detail is how the window manager
implements click-to-focus:

• The WM establishes a pasive grab on each unfocused toplevel
  window using XGrabButton()
• A passive grab is where events are delivered as normal until a
  specific key or button combination is pressed and an active grab
  is established causing the event (and following events) to be
  delived to the grabbing client.
• The WM passes GrabModeSync to XGrabButton()
  which causes all event delivery to freeze when the specific
  key/button combination is pressed.
• So, when a user clicks on an unfocused window, all subsequent
  events are queued in the Xserver, the WM gets the ButtonPress,
  focuses the toplevel of the window which was clicked in and
  releases the event queue again using XAllowEvents()

In case its not obvious, I’m only really writing this down so there’s
less chance of me forgetting it all again 🙂