From: keith@expo.lcs.mit.edu (Keith Packard)
Message-Id: <8908162037.AA07121@xenon.lcs.mit.edu>
To: Todd Brunhoff <toddb%tekcrl.labs.tek.com@relay.cs.net>
Cc: keith@expo.lcs.mit.edu, xvideo@expo.lcs.mit.edu, keith@expo.lcs.mit.edu
Subject: Re: Comments on VEX version 3.4 (89/08/02) 
In-Reply-To: Your message of Wed, 16 Aug 89 11:01:41 -0700.
             <8908161801.AA16386@tekcrl.LABS.TEK.COM> 
Date: Wed, 16 Aug 89 16:37:06 -0400


I'm still not happy about the visuals stuff, but I'll let it slide for 
a few days.

> > I think this event should indicate which request it was associated with;
> > perhaps the serial number of that request should be included.
> 
> I intended to take advantage of the same description used by the
> core protocol, and will include it explicitly at the beginning of
> the event section:
> 
>     Every VEX event also contains the least-significant 16 bits of the
>     sequence number of the last request issued by the client that was (or
>     is currently being) processed by the server.

This was not my point at all; of course the event will contain the
sequence number of the last request processed.  But, if the device is
*very* slow about changing state (which, I presume, is the reason this
event exists), several requests may have been processed since the state
change request.  It would be useful to have the sequence number for the
state change request inside the event so that they could be correlated.

Now then, about the Tek bits.  The header files are not exactly clear on
how the frame buffer is mapped, and how /dev/xdev works exactly.  Even some
very terse pointers on how to get it working would be useful.  After all,
I came through with *my* end of the bargin.

As to performance; we've been running the 4.0 X11 server and comparing it with
my sun 3/60 numbers (a reasonable comparison, I think).   It looks like the
magic hardware is not being used for CopyArea (except in aligned cases), nor
does the magic hardware speed up text operations at all.  Text painting is
obviously CPU limited -- the Tek box is slightly slower than the 3/60 (about
10%) and quite a bit slower than the PMAX (about 4.7 times).  We'll have to see
how redwing turns out.  Scrolling is impressive though; 2/3 the speed of the
monochrome PMAX, 5 times faster than the color PMAX.  Rectangle filling as well;
solid rectangles run 3 times faster than the 3/60 (and the PMAX).  Tiled
rectangles, however, are only about 30% faster.

So the magic hardware wins for at least three operations:

	Scroll			-	5 times faster
	Solid fill		-	3 times faster
	Tile fill		-	30% faster

Where the hardware isn't being used though, things are less exciting.  For
example, non-aligned copyarea is substantially slower on the tek box; 
half the speed of the PMAX, about 2/3 the speed of the 3/60.  Although this
may not seem as important now, while terminal emulators are still the
most common application, I expect plain bitblt to play a larger role in
the future.

I expect to see impressive numbers for stipple fill as well; the magic
should make quite a bit of difference; however I haven't written
any color stippling code yet.

So, if you'll attempt to get me some level of Tek hardware specs, I'll
flame you about visuals again.