jonasn@ttds.UUCP (Jonas Nygren) (05/18/89)
When trying out X on a DEC3100 with dxwm, DEC's window manager, I ran a small
program which drew arc's in a window, and I was astonished by the speed, or
rather the lack of speed. In a 300 by 300 window the following code was
executed (monochrome, only Xlib, after necessary initializations):
t = time(0L);
for(i = 5; i < 3000; i += 10)
XDrawArc(disp,win,gc,0,0,i,i,90*64,90*64);
XSync(disp,0);
printf("Time: %ld s.\n",time(0L) - t);
The time reported was 238 s !!! Is this fast or slow in X-reality?? I tried out
the same code on a Mac (using Mac-OS, Quickdraw etc, NOT X) and with the same
window size and the same for-loop the measured time was 32 s !!!
The DEC3100 is approx 20-25 faster than my MacPlus on integer operations which
indicates that the Mac is approx 140 (238/32 * 20) times more efficient than
the DEC3100 regarding this graphic test. Could anybody tell me what is
happening in the X-code ???
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. Is such
a behaviour normal when running X standalone on a workstation or is this
something DEC-specific ??? Is there anything I could do to alter this ???
/jonas
Newsgroups:
Subject:
Reply-To: jonasn@ttds.UUCP (Jonas Nygren)
Organization: The Royal Inst. of Techn., Stockholmrws@EXPO.LCS.MIT.EDU (05/18/89)
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.envbvs@epb2.lbl.gov (Brian V. Smith) (05/18/89)
In article <8905181301.AA00183@expire.lcs.mit.edu>, rws@EXPO.LCS.MIT.EDU writes: > Path: > > 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. Or possibly ALL of the arc requests have already reached the server and it is just faithfully carrying out its orders. When I start up xfig, if I stop it with a STOP signaljust a few seconds after starting it up, the shell says it is stopped, but 10 or 15 seconds later, most of its windows (widgets) appear on the screen. All (or most) of the information has been sent by the client to the server, but the server is still processing it. _____________________________________ Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory We don't need no signatures!
rws@EXPO.LCS.MIT.EDU (05/19/89)
Or possibly ALL of the arc requests have already reached the server and it
is just faithfully carrying out its orders.
That's why I said it's a matter of scheduling in the server. Just because
the requests have arrived doesn't necessarily mean the server will ignore
keyboard input. You have to understand the particular server's scheduling
policy about when and how many requests it executes before rechecking for
device input.fisher@moon.dec.com (05/19/89)
Jonas Nyrgen asks about the speed of arcs on a DECstation 3100 vs a MAC. I am not a MIPS or Ultrix heavy (I'm from VMS, actually), but you need to consider that you are not really comparing apples to Apples (ahem :-) ). Seriously, the X protocol specifies arcs quite precisely, but in general, it is quite expensive to implement this spec. Have you tried comparing (width=0) lines? How about text? Etc. Burns
joel@gilroy.pa.dec.com (Joel McCormack) (05/19/89)
The original release of the DECStation 3100 used the R3 code for arcs. This code is slow. The next release uses the code that Keith Packard has done for R4, which runs 2 to 8 times faster on circles, and about 50% faster on ellipses. This is still slow. In particular, I have convinced myself that 0-width arcs can run about a zillion times faster than they do now, using all integer arithmetic, and still get the right pixels set. I'm pretty convinced that wide arcs can run a lo
jg@max.crl.dec.com (Jim Gettys) (05/20/89)
I am responding, as Joel McCormack's building is having network trouble. BTW, it is the server, not the library.... The R3 arc code, as originally distributed, is EXTREMELY slow. For the first time, it matched the specification. Unfortunately, the specification as written is very difficult to implement correctly (we did not realize this at the time it was written. Sigh....). PMAX (DECstation 3100) is using an R3 based server. We did not realize how slow the arc code was at the time, or we would have done something about it.... Since R3 first came out, there have been improvements in the code to the point where it is merely slow; it will be at least 3x faster in the next release (Ultrix 3.1, UWS 2.1), according to the performance data I have. More work needs to be done yet. BTW, most graphics operations in the next release on the color display will be very much faster than the first release, in which only text, line drawing and basic raster operations had been optimized. Factors of two or more improvements in other graphics areas are common; even the items which Joel had had time to optimize for the first release are faster yet. Jim Gettys Cambridge Research Laboratory Digital Equipment Corporation