On Sun, 26 Sep 2010, Alan Coopersmith wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
xwininfo is a command-line utility to print information about windows on an
X server. Various information is displayed depending on which options are
selected.
The major new feature of this release is the rewrite to use libxcb instead
of libX11, batching requests for information to reduce waiting on round-trips
in gathering the client information from the X server. Testing over a
high-latency connection from California to China and back resulted in an
improvement from 8 minutes to 45 seconds to output the complete window tree
via xwininfo -root -all of a GNOME desktop session with 114 windows.
This release thus libxcb to build, (though it still requires some libX11
headers as well). It also requires a minimum xproto version of 7.0.17.
Should anyone need to maintain the libX11 version, a 1.0.x branch can be
created in git from the 1.0.5 release base as needed.
This release also adds support for reporting some EMWH window manager hints,
including UTF-8 localized window names from the _NET_WM_NAME property.
(This version does not correctly display names for windows with the WM_NAME
property set using the COMPOUND_TEXT encoding. Most current desktops &
toolkits will set the _NET_WM_NAME, which is used in preference to WM_NAME
if it is set.)
Nice work :) Though, I have 2 remarks:
1) Why a file for strnlen that is used only once in xwininfo.c ?
2) You query at the beginning some netwm atoms. Just after, line 548, you
can exit because the window with a name is not found. You should here get
the replies of the requested atoms. If I'm not mistaken, you have to get
the replies to free the memory in the server.
3) You can speed up things even more. As you know that shape extension has
to be initialized, you can query it at the very beginning. The
initialization can then be done like that:
a) create the connection
b) First round trip:
* you request the atoms
* you prefetch the shape extension data if needed
* you do some thing that takes time here (get the screen number,
verify the window, etc...)
* you get the atoms
* you ask for the shape extension data if needed
c) Second round trip:
* you request the QueryVersion for the shape data (if needed),
GetGeometry, and other requests if any
* you do some things that take time here and can be done in the first
round trip (if any)
* you get the reply of the QueryVersion (if needed) and GetGeometry
requests etc..
It's a micro optimisation of course, but why not being optimal ?
best regards
Vincent
_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
