nanogui: Re: [linuxce-devel] Microwindows architecture explained
Subject:
Re: [linuxce-devel] Microwindows architecture explained
From:
"Greg Haerr" ####@####.####
Date:
31 Oct 1999 18:07:07 -0000
Message-Id: <003a01bf23b8$f5e8e9e0$15320cd0@gregh>
----- Original Message -----
From: Jay Carlson ####@####.####
: I think I figured out why Nano-X is so slow. All requests, even just
: drawing single pixels, involve a round trip to the server. When a drawing
: request is sent to the server, the client blocks until it reads the one-byte
: reply.
Alex knows his code is slow, and was going to rewrite it. I think your
critical insight about the when the client and server processes context
switch should drive the design. That is, just like X, _all_ requests should
be buffered until the next call to GetNextEvent, unless they absolutely
require information from the server, like GetInfo requests. We can also
assume that the client/server connection is reliable (hell, it's not even UDP,
it's UNIX sockets...) so there's not a big need to error check the status.
I'll take a look at the X protocol and see whether there's a wire-level
synchronization
capability in the rare case that things really do get hosed up.
:
: X is a good deal smarter about this. Most operations, including drawing, do
: not require a reply. Error conditions are treated like events and signalled
: asynchronously.
:
Although more complicated, an async error event is a good idea. If we're using
UNIX sockets, it's unlikely this will ever happen.
: This is particularly clever because it allows both the client library and
: the underlying pipe/TCP stream/etc to buffer requests. Any client operation
: that really requires a reply flushes the outbound request buffer.
:
: Consider a Nano-X client wanting to draw ten lines and then wait for an
: event. Each small request blocks the client until the server issues its
: reply, so we must context switch at least twenty times. With X-style
: buffering, the ten line draw messages get pushed all at once and then the
: client waits; the server then chews its way through the received requests
: and will context-switch back to the client when there's actually an event.
:
: I don't enough about X to hate it the way some people do, but the core X
: protocol and some parts of Xlib look like they were designed by very smart
: people.
:
: Jay
I'll add a client/server rewrite to the list, and try to push up it's priority.
Greg
