solomon@speedy.cs.wisc.edu (Marvin Solomon) (08/03/88)
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:
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?
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!
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 can't get XCopyPlane to work at all. I have a little program that makes
a square bitmap (one-plane pixmap) fills half of it with zeros and half with
ones, and then does an XCopyPlane to a window of the same size.
Depending on the size of the bitmap and the foreground and background pixels
used in the GC used for the copy, I get all sorts of weird results, including:
all white, all black, half and half (correct), various strange patterns of
misc garbage, and once even half white and half very light gray. (I got that
one with foreground=background=0 in the copy GC). Sometimes, the window
seems to be drawn twice in quick succession with different patterns.
I can't swear to it, but it seems that sometimes the contents of the window
are leftovers from a previous run of the program! I tried XGetImage on the
pixmap and on the window; the former looks ok, but the latter seems to be
garbage.
Excerpts from my test program appear at the end of this note. I can supply
the whole thing on request. By the way, DefaultDepth() returns 4, but
"xrdb -query -symbols" returns:
-DHOST=unix -DWIDTH=1024 -DHEIGHT=864 -DX_RESOLUTION=2960
-DY_RESOLUTION=2959 -DPLANES=8 -DCLASS=PsuedoColor -DCOLOR
Any help at all would be greately appreciated.
Here are the excerpts:
main()
{
server = XOpenDisplay(...);
screen = DefaultScreen(server);
bd = BlackPixel(server, screen);
bg = WhitePixel(server, screen);
fg = BlackPixel(server, screen);
printf("On this display, WhilePixel=%d, BlackPixel=%d\n",
WhitePixel(server, screen),
BlackPixel(server, screen));
printf("default depth=%d\n",DefaultDepth(server, screen));
printf("window dimensions:"); scanf("%d",&WIDTH);
HEIGHT = WIDTH;
printf("window background:"); scanf("%d",&bg);
window = XCreateSimpleWindow(server, DefaultRootWindow(server),
1024-WIDTH-4, 0, WIDTH, HEIGHT, 1, bd, bg);
XSetStandardProperties(server, window, ...);
XSetWMHints(server, window, ...);
canvas = XCreatePixmap(server, DefaultRootWindow(server), WIDTH, HEIGHT, 1);
DrawGc = XCreateGC(server, canvas, 0, &gcv);
printf("copy foreground, background:"); scanf("%d %d",&fg,&bg);
gcv.foreground = fg;
gcv.background = bg;
CopyGc = XCreateGC(server, window, GCForeground | GCBackground, &gcv);
XSelectInput(server, window,
ExposureMask | ButtonPressMask | ButtonReleaseMask );
XMapWindow(server, window);
for(;;) {
XNextEvent(server, &event);
if (event.type == ButtonRelease) {
XDestroyWindow(server, window);
exit(0);
}
if (event.type == Expose && event.xexpose.count == 0) {
while (XCheckTypedEvent(server, Expose, &event));
ReDisplay();
}
}
}
ReDisplay()
{
XSetForeground(server, DrawGc, 0);
XFillRectangle(server, canvas, DrawGc, 0,0, WIDTH/2, HEIGHT);
XSetForeground(server, DrawGc, 1);
XFillRectangle(server, canvas, DrawGc, WIDTH/2,0, WIDTH/2, HEIGHT);
XClearArea(server, window, 0, 0, WIDTH, HEIGHT, False);
XCopyPlane(server, canvas, window, CopyGc, 0, 0, WIDTH, HEIGHT, 0, 0, 1);
}
Marvin Solomon
Computer Sciences Department
University of Wisconsin, Madison WI
solomon@cs.wisc.edu or seismo!uwvax!solomonRWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/08/88)
Date: 2 Aug 88 19:41:07 GMT
From: solomon@speedy.cs.wisc.edu (Marvin Solomon)
Is anybody running X11R2 on a Vaxstation 3200 (also known as Microvax III)?
Yes, but on an 8-plane system, not a 4-plane system.
1. It seems to have a storage leak somewhere.
We haven't tracked this down yet.
I dimly recall a report of this problem on a Sun. Was there any resolution
to that problem?
My tests on a Sun have not yet produced any storage leaks.
It seems to be the XDrawText() calls that are slow [to pixmaps].
Yes, the qdss server uses the MI code when drawing to pixmaps, and as a result
it is very slow.
Second, gray scales other than black or white don't seem to work. I tried
XFillRectangle() with pixel values from 0 through 15.
If you didn't actually allocate any colors, then I'm not surprised it
didn't work, unless you actually created a StaticColor map and installed
it before drawing.
I can't get XCopyPlane to work at all.
We've very recently fixed some problems here, but they haven't been fully
tested (e.g., I don't know if they fix the QDSS).keith@EXPO.LCS.MIT.EDU (Keith Packard) (08/08/88)
> > 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