[Desktop_architects] Making X more responsive Was: Linux desktop, the fun thread

[Keith Packard]

On Wed, 2005-12-14 at 16:22 +0100, Martin Konold wrote:

> Keith: I can assume that in the case of congestion it is not really desireable 
> to inform all clients about every small mouse movement. I can imagine that it 
> is useful to introduce a more relaxed semantic when congestion(*) happens.

The X server already compresses sequential motion events which are
processed at the same time into a single event to the clients. This
means that when busy, the X server will automatically reduce motion
events somewhat. It doesn't, however, do any analysis of the environment
to determine when it should wait briefly for additional motion events
before delivering what it has. 

I did have some motion timeout code in a network-dependent X
implementation that would actually hold events for a short time awaiting
additional motion to rate limit packets coming out of the device. I'm
not sure we want to go back to that kind of code though; it artificially
reduces the mouse precision seen by applications.

> Can these problems with memory allocation be somewhat dampened by using some 
> smarter memory pooling algorithm which can claim memory from preallocated 
> space?

There really shouldn't be a huge issue here; for motion event delivery,
there aren't any allocations going on in any case. That's really the
easiest solution. Memory allocations in the X server are largely limited
to window manipulation and explicit resource allocation. There aren't a
lot of allocations done in the handling of rendering requests.

> Keith: Please comment if some memory pooling within the X server can be a 
> remedy. In general due to the fact that kernel roundtrips are expensive such 
> pooling might speed things up significantly in the general case. Qt does such 
> a pooling since many years very successfully (e.g. QString).

X was designed when the fastest allocator was the original BSD version,
and most Unices were still using a varient of the first-fit V7 version.
The implementation has a pathological avoidence of allocation as a
result.

> Without proper testing I don't know if relaxing the notification will break 
> existing semantics (e.g. Linus' focus-follows-mouse (**) usage). But I am 
> rather confident that it could be made right.

We already have relaxed motion notification semantics, and
demonstrations in older implementations of very lazy updates that work
reasonably well. That was in an embedded environment which had no
separation between operating system and X server though.

One issue with that older implementation involves scheduling within the
X server; we continue to struggle with how to perform reasonable
scheduling of operations in a user-mode application with
human-interaction latency bounds.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.linux-foundation.org/pipermail/desktop_architects/attachments/20051214/35315c02/attachment-0001.pgp