Path: utzoo!attcan!uunet!husc6!bloom-beacon!EXPO.LCS.MIT.EDU!keith
From: keith@EXPO.LCS.MIT.EDU (Keith Packard)
Newsgroups: comp.windows.x
Subject: Re: X11 on a Vaxstation 3200
Message-ID: <8808081645.AA03091@EXPO.LCS.MIT.EDU>
Date: 8 Aug 88 16:45:36 GMT
References: <6092@spool.cs.wisc.edu>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 66

> 
> Is anybody running X11R2 on a Vaxstation 3200 (also known as Microvax III)?  
> The "black and white" version of this thing actually comes with a qdss
> ("color") interface with 4 planes.  I'm running 4.3BSD Unix.
> It works fine (in fact, is extremely snappy) EXCEPT:

I'm using a 3200 here at the consortium.

> 
> 1.  It seems to have a storage leak somewhere.  Each time you create a
> window, the size of the Xqdss process gets a little bigger, and does not
> get smaller when the window goes away (or the program exits).
> I've reported this to the 'bugs' address, but haven't yet received a reply.
> I dimly recall a report of this problem on a Sun.  Was there any resolution
> to that problem?  

We've been using some memory leak programs to attempt to locate memory
lossage in the server, so far we haven't seen anything...

> 
> 2.  There seems to be something very wrong with pixmaps.  This is a little
> harder for me to put my finger on, but here are some symptoms:
> 
> First, an application (my xproof program, which I was planning to release last
> week, before these problems set me back) that runs fine on other machines
> runs EXTREMELY slowly on this machine.  It does a whole lot of XDrawText()
> calls to a pixmap, and then does an XCopyArea() call on expose events.
> It seems to be the XDrawText() calls that are slow.  The program takes
> a couple of seconds to draw a page on a Vaxstation 2000 with a qvss B&W
> display, and a fraction of a second on a B&W Sun 4/110.  On the 3200, it
> takes about 30-40 seconds!

Well, off screen pixmaps are implemented *entirely* using mi code -- the
only routines written were the spans routines.  This makes off-screen
drawing painful.  If you want to make it use cfb code where possible, we'd
be happy to distribute it.

I've been playing with backing store for the Qdss (in R3) and have seen
massive performance degradation drawing to obscured regions of the display.
A typical example is the 5-7 seconds per scroll in xterm...

I don't have the time to make this work correctly though, the Qdss
off-screen pixmaps are slightly different than cfb pixmaps, to make it work
correctly, you'd have to change that.

> 
> Second, gray scales other than black or white don't seem to work.  I tried
> XFillRectangle() with pixel values from 0 through 15.  0 and 14 draw as
> white, while all others show up as black.  BlackPixel() and WhitePixel()
> are 15 and 14, respectively, so maybe this is "right", but something still
> seems wrong.

I suspect that the monochrome hardware isn't analog somewhere.  However, I
don't have a mono system, so I don't really know.  Our 4 plane color 2000
system works just fine.

> 
> I can't get XCopyPlane to work at all.

CopyPlane is broken in Xv11r2 for the Qdss.  I don't think it was ever
tested or debugged.  

						Keith Packard
						MIT X Consortium
						(617) 253-1428
						keith@EXPO.LCS.MIT.EDU