Path: utzoo!attcan!uunet!lll-winken!xanth!ukma!rutgers!apple!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU
Newsgroups: comp.windows.x
Subject: Re: DEC3100-Xlib performance
Message-ID: <8905181301.AA00183@expire.lcs.mit.edu>
Date: 18 May 89 13:01:39 GMT
References: <1201@ttds.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 30


    Is this fast or slow in X-reality??

Yes.  (Reality is like that.)

You didn't indicate what line width you were using.  A line width of zero
could definitely go *much* faster that it does in many X servers I've seen,
but I suspect people have been applying their energies at more common
operations.  Even for non-zero line widths there are various speedups that
can be applied (especially for circular arcs).  I couldn't tell you what
Digital has or hasn't done in this area.

    Could anybody tell me what is happening in the X-code ???

Lots of arithmetic, much of it probably floating point.  It's a long story.
You have to go read the protocol specification of arcs very carefully, and
discover all the ways in which you can get it wrong.  The X definition is
not the same as the Quickdraw definition.  You can argue that the X definition
is wrong.  You wouldn't be the first.

    When I tried to break this test with ^C's I found out that the system no
    longer responded, indicating that the X-server had some abnormal priority.

It probably doesn't have that much to do with priority, although it's possible.
Your keystrokes have to go through the server to get to the application.  The
server is busy drawing a bunch of arcs, and isn't paying much attention to your
input.  This is a matter of scheduling in the server, more than priority.  It
is possible that your server is running at higher priority than your shell, in
which case even if the server dispatches the keystrokes they might not get
processed, since the server will go back to drawing those arcs.