From: Caolan McNamara (Caolan.McNamara at domain ul.ie)
Date: Thu 05 Aug 1999 - 16:42:04 IST
On 05-Aug-99 Paul Jakma wrote:
>
>
>> This is not a X is bad argument, or a call for a specialized
>> extention, just an
>> investigation into an interesting implementation /
>> enhancement of an XServer.
>
>something i was thinnking of: the majority of X requests are from toolkits,
>qt, gtk+, motif.. whatever.
>
>why not add a toolkit extension to X? Ie something where a toolkit could
>register a set of X procedures with the X server. And from there on the
>toolkit could refer to the procedure (possibly with parameters) instead of
>having to send all the low-level X stuff again.
>
>eg, gtk+ could register a GTK_scrollbar <with parameters> procedure with the
>Xserver, and give it the X commands needed, which the X server caches. From
>there on that instance of gtk+ could ask for GTK_scrollbar..<up, x,y,
>whatever> and the Xserver would know what to do.. so smoother scrolling.
>Less system time taken up with passing X requests around, so more time for
>passing important stuff across the wire, like pixmaps, etc.
>
>A new instance of gtk+ could check first to see if something is registered,
>and if it is bypass the registering procedure.
>
>it'd cause a slight memory bloat granted, but not that much. I'd guess no
>more than 1MB even with a couple of toolkits active.
Im not so sure about that one, basically cache frequenty called sequences of
routines and associate a single message id with them ? Send one request to
"scroll window and all subsindows upwards by X", rather than multiple calls to
move all the subwindows and the parent seperately ?
Something like that would offer some speed advantages, but I suspect that it
would be reasonably small. What you want to do is in effect move chunks of
the gtk toolkit (or whatever) logic into the Server itself? No great harm I
suppose, and in the case that the extension can't be found you fall back to the
standard way of doing it. Hmm, yeah i think in principle you could do it.
I think first we have to find out where X spends most of its time and space and
reduce that. If as the sgi paper suggests, its the time spend serializing and
unpacking the message passing, then something like this where you are basically
compressing the sequence of protocol messages to achieve something to a single
protocol message to the Xserver to do the complicated gtk task, would reduce
this bottleneck.
You only get a substantial advantage if the actual gtk functions actually *are*
doing a lot of X work. Many of the gdk calls are just wrappers around single
X functions, so no there'd be no advantage there at all for gdk.
The more I think about it the less i'm sure one way or the other about this one.
The bigger the gtk calls and the more work they do for you the better this will
work. If the gtk calls are short and have small well defined functions, then its
not really worth it.
I believe that a lot of the problem is when you request something from the
Xserver. When you are pushing *to* the Xserver your calls are buffered and
only flushed when a) the buffer files b) you request something from the server.
So every time you ask the server for something you lag it down, so it might
depend more on how much does gtk widgets request *from* the server.
I think its a worthwhile idea alright, and it just might work. One small catch
would be that every tom dick and harry toolkit would want in on the act :-). One
could compare gtk in the server vs no gtk as a CISC vs RISC style argument.
Where the compiler (client app) would rather have more complex instruction in
the chip (Xserver) so as to make his life easier, and the expense of making the
chip more complex, and requiring a stack more logic. I reckon that if the D11
think could be gotten off the ground that'd it be a hell of a lot easier to sell
as a concept. Of course as D11 is the exact same as X11, you could do both :-)
C.
>
>feasible?
>
>paul.
Real Life: Caolan McNamara * Doing: MSc in HCI
Work: Caolan.McNamara at domain ul.ie * Phone: +353-86-8790257
URL: http://www.csn.ul.ie/~caolan * Sig: an oblique strategy
What are the sections sections of?
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:04:26 GMT