From: Caolan McNamara (Caolan.McNamara at domain ul.ie)
Date: Fri 06 Aug 1999 - 10:02:42 IST
On 05-Aug-99 Paul Jakma wrote:
>
>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.
Have you a url for this paper, so i can have a skank at 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.
>
>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.
from the sgi paper i get.
[... the buffer are flushed when...] a reply needs to be received, an
explicit XFlush call has been made, the buffer is full, or Xlib is asked
to detect incoming events or errors
This would mean that if you send a stack of drawing messages down the wire,
then they are all buffered until (ignoring the full buffer case) the app
asks for an event. So as soon as the app checks to see if any events that it
is interested in have arrived the buffer is flushed. So it looks like the X11
isnt asynchronous in both directions, incoming events automatically flush
outgoing events, which when you think about it makes a whole lot of sense to
avoid racelike conditions when a click is received in a drawing area which
hasn't been updated with the new image sitting in the buffer.
e.g.
100 * XDrawLine (all of then are queued up in the output buffer)
XNextEvent (wait for the next registered event, *pow* off goes the buffer)
The man page for XNextEvent says that it "flushes the output buffer and
blocks until an event is received", so we are guaranteed that the output
buffer is only a holding house until you want something back from the server,
so the quality of buffering is dependant on how often you ask for something
from the server.
I think another issue is some calls like XGetImage automatically create a
return from the server, and thus cannot be buffered. I believe that a Pixmap
is a resource that lives on the server, and a XCopyArea from one to the other is
only a directive to the server to copy something between two of its own resource
and so can be buffered, but an XGetImage cannot as it returns its data all the
way back to the client. So each call to XGetImage flushes the buffer. I imagine
that there are quite a few calls like this, though mind you the XShm extension
eliminates most of this issue seeing as the data doesnt have to be copied as
many times about the place from
Screen to Server to protocol sequence to client to protocol decoder to final
image,
but rather from Screen to ShmImage ? (maybe theres a few more copies in there)
>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.
DRI is a different issue from something like D11. In DRI you get to draw direct
to the framebuffer. Its going to be cool for vrml/3d games and so on. Bit chunks
of data being blasted at the screen, i suppose you can look at it as a sort of
souped up uber XShm extension. But for your common or garden app like netscape/
staroffice/xterm is has no relevence. And as it happens the DRI infrastructure
(setting up the thing, and communicating and so on) still occurs over the X
protocol (well obviously i suppose) which still gets squished through the
standard paths of the domain socket in the local case. or at least my reading of
http://www.precisioninsight.com/dr/drill.html affirms my belief in its purpose.
C.
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