[ILUG] D11, basically implement X11 server like an os kernel

[Paul Jakma]

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
slashdot page.

  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
  it.

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. 
  
  C.

regards,
-- 
Paul Jakma
paul at clubi.ie	http://hibernia.clubi.ie
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
-------------------------------------------
Fortune:
Don't be humble ... you're not that great.
		-- Golda Meir