Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!pa.dec.com!jensen
From: jensen@wrl.dec.com (Paul Jensen)
Newsgroups: comp.windows.x
Subject: Re:  How to get 24-bit pictures on DECstation 5000/200PXG?
Keywords: DECstation PX PXG 24planes
Message-ID: <1991Feb7.221431.9199@pa.dec.com>
Date: 7 Feb 91 22:14:31 GMT
References: <9102020056.AA25076@hydro.Saic.COM> <15870.27b18964@levels.sait.edu.au>
Sender: news@pa.dec.com (News)
Organization: DEC Advanced Technology Development, Palo Alto, CA
Lines: 47

>We would very much appreciate any advice
>from users with actual experience of these PX and PXG 24 bit plane
>options, to help us work out how to respond.

By all means communicate with other users, but be sure
1) that their application is similar enough to yours for comparisons
to be valid; 2) to filter out unsubstantiated reports of problems,
problems with low information content, and problems which have been
corrected in subsequent releases.

The rendering chips used in the PX[G] options were designed primarily
to accelerate 2D & 3D drawing operations (points/lines/triangles).
For the most common cases (e.g. 0-width solid lines), these primitives
are 2-4 times faster than the DS3100 (as measured by X11perf), while
using fewer host cycles.  Applications depending on XDrawSegments
or XFillPolygon should run at hardware speed: I would be interested
(as one of the principals of the PX[G] server port) in hearing
*specific details by mail* about cases where this is not true.

Imaging is more of a problem, because of two limitations in the
PX[G] hardware: pixel-level access to the frame buffer is slower
than the cfb options; and there are only 1.3-3.9 Mpix of offscreen
memory available.  Contention for offscreen memory (which can
be caused by cycling through a large set of pixmaps) is usually
a worse problem than the slower access to the frame buffer.
This does not imply that image display on the PX[G] is necessarily
unacceptable: it does mean that achieving peak performance
requires more care, and there are definitely some tar pits to avoid.

Tuning graphics software is a tricky business, requiring knowledge
of many factors, including the primitive mix, and the ratio of graphics
to non-graphics computation.  Some time back I wrote a white paper
discussing hardware differences between the PX and "dumb" frame buffers,
and coding ramifications thereof.  Much of what I said there also applies
to the PXG.  Even if you are not actively developing grahics software,
you may find this useful.  You should be able to get a copy from your DEC
sales rep: the title of the paper is "A Guided Tour of the PX Graphics
Option" (or some close approximation).

I would suggest that followups be directed to comp.sys.dec, or conducted
by mail, in order to keep this newsgroup from growing beyond its present
unmanageable :-) size.

--
					/Paul Jensen
					 Digital Equipment Corp.
					 Palo Alto, CA