Re: [tlug] Weird problem with xine and KDE

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Godwin" == Godwin Stewart <gstewart@example.com> writes:

    Godwin> Is there a way to get the ID of the window SENDING the
    Godwin> message?

The unhelpful (in the short run) answer is, "No, windows don't send
events (the particular kind of message you're tracing here), the
server does.  Window only receive events."  Of course, the server
sends events in response to client requests, so what you want to know
is what client is sending the requests.

What happens in Xt (and I presume GTK+ and Qt, as well) is that each
widget has a geometry manager.  When you want to make a change in a
window's configuration, you call the geometry manager, which then
negotiates with the window's parent.  If the window's parent is owned
by the same client, it all happens within libXt.  If not, then the
client sends a ConfigureRequest to the server, _which can be denied or
altered_ by the server, so the client has to wait for a
ConfigureNotify event in that window, and then adjust its own idea of
the window's geometry according to the properties in the
ConfigureNotify event.  It can't really argue about it, you see---the
server is always going to win.

The way a window manager works is to take responsibility for
geometry management of the root window.  It intercepts window creation
calls, creates an otherwise empty window just large enough to swallow
the desired window as a child of the root, then reissues the window
creation call with its "shell" window as the parent of the new
window.  After that, it's all automated by standard Xt callbacks.

There may be better ways of doing this, but that's how it works in X.
Remember, the server, the window manager, and the client may be
running on three different CPUs, and X protocol to the server is the
only communication channel known to be available to both the WM and
the client.

In order to trace the source of the configure requests, you'd need to
monitor all protocol requests to the server, because that information
is not part of the event sent to the window.  It can be done, but I
don't know how offhand.  To interpret it, you need to know the kind of
thing I just explained, and once you know that, you can usually guess
where in the source the problem is.  The problem is how to achieve the
functionality without triggering the bad behavior.

Since toolkits are very high-level beasties, it's rarely possible to
fix this kind of thing at the level of compiler switches or user
options.

    >> Also, can you see a flicker or anything like that in the GUI? 
    >> Does the GUI have a dynamic display in it?

    Godwin> No flicker, and there's no real dynamic display - just a
    Godwin> slider moving along slowly, marking the elapsed time.

By dynamic I mean "asynchronous compared to user generated (mouse or
keyboard) events", so this is dynamic enough.  Actually, from the X
server's point of view, this can involve _more_ protocol traffic than
(eg) a fancy twirler.  Eg, netscape's "I'm downloading" shooting star
animation.  That is probably implemented as a sequence of pixmaps, so
once they're stored in the server, it's _one_ proto-call per frame.
Whereas the slider is probably implemented as a dozen or so rectangle
or trapezoid fills, each requiring a proto-call, to implement
shading for each frame.

I wonder if xine is unmapping the window to avoid flicker and then the
window manager (presumably kicker) is doing a Configure dance on every
one-pixel displacement of the slider.  How fast do those events come?

You know, if you were running Windows you wouldn't have this problem.
;-)


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.