On Thu, 5 Aug 1999, Caolan McNamara wrote:
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 ?
exactly. very similar to display lists in GLX. Basically server side
caching, but the client decides what should be cached. Also i was
thinking to possibly allow parameters in some way, so that what's
cached can be dynamically altered. eg to specify the length of a
scrollbar. It should be fairly trivial for the X server to draw a
longer scrollbar, provided the client told it how to when registering
the scrollbar procedure.
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 it might offer some advantages. Eg GLX clients that make
extensive use of display lists run very fast, (eg the OpenGL demo
gears runs at 200fps on my computer).
Then there's also the cumulative benefit when there are many clients.
The reduction in bandwidth used per client might typically be small,
but the cumulative saving might just be enough to make a difference
to that one app you're running that needs to move a lot of dynamic
uncacheable data across the socket, eg netscape scrolling a long
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.
I read a DEC whitepaper about GLX, and one of the points was that
with good use of display lists, loss of performance due to X overhead
is negligible. But I'm only guessing - i have no real experience
myself about where the real bottlenecks are.
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.
I don't know any of the internals of gdk. I guess drawing a single
button isn't too complicated. But i'm thinking more of complicated
widgets, like menu's, scrollbars and such.
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
agreed. so info is needed on how many X messages each gtk+ widget
needs, and also on which gtk+ widgets are used most often in typical
programmes. Then we'd have an idea of potential gains. Again, i've no
facts. (anyone handy with profiling tools?)
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.
AFAIK X11 is totally asynchronous in both directions, unless the
client specifically requests otherwise with XFlush/Xsync. You send
messages to the X server, and the X server sends events back. With
absolutely no relation between the two. So in theory it shouldn't
make a difference. Anyway, it can only speed things up - without this
extension the server has to process the X stream, and render it.
With, the X server doesn't need to decode much, it already has the
procedure and can get straight to work on rendering. The only real
cost is memory.
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.
Well RISC is clearly superior! (oops wrong thread.). It's not about
'gtk in the server'. It'd be far more generic than that. It'd be a
way for any client to store a set of rendering procedures in the
server along with info on how to do basic modifications, (eg
length/width/colour), and refer back to it later.
The biggest benefit would obviously be when using a standard
programming widget library across all your apps.
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 :-)
Yeah, D11 sounds cool aswell. But it's superceded by direct rendering
i think. Performance will be optimal as the client wirtes directly to
framebuffer, no X overhead at all.
paul at clubi.iehttp://hibernia.clubi.ie
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
Don't be humble ... you're not that great.
-- Golda Meir
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!