Path: utzoo!attcan!uunet!crdgw1!uakari.primate.wisc.edu!uflorida!haven!decuac!bacchus.pa.dec.com!basalt!allen
From: allen@basalt.uucp (Allen Akin)
Newsgroups: comp.sys.dec
Subject: Re: X performance on DEC5000
Message-ID: <1990Oct25.190604.28904@wrl.dec.com>
Date: 25 Oct 90 19:06:04 GMT
References: <5239@mit-caf.MIT.EDU> <1990Oct16.033743.4246@wrl.dec.com> <5282@mit-caf.MIT.EDU>
Sender: news@wrl.dec.com (News)
Reply-To: allen@atd.dec.com (Allen Akin)
Distribution: na
Organization: DIGITAL Advanced Technology Development, Palo Alto, CA
Lines: 29

In article <5282@mit-caf.MIT.EDU> rajeev@caf.mit.edu writes:
>                  ...  Does the PixelStamp chipset support the X line
>drawing primitives or is the 2-3x performance boost only for width=0
>lines?

The chipset accelerates the so-called ``zero-width'' X lines (which
happen to be one pixel wide on all X servers that I've seen).  I don't
think there's any significant performance boost for wide lines, though
I could be wrong for very wide lines.

I'm a little confused by your question -- zero-width lines *are* X line
drawing primitives, as are wide lines.

>   ...  Also, does X have similar guidelines for rendering filled
>polygons, and if so, does PixelStamp support those primitives also?

The PixelStamp polygon-drawing semantics match those for X convex
polygons, so it accelerates those nicely.  Nonconvex polygons are
tesselated by the server to form convex subpolygons in some cases,
or scan-converted directly in others.  There's always a performance
advantage in using convex or non-self-intersecting polygons.

For all primitives, performance is best for solid fill-style, stippled
fill-style where the stipple has power-of-two dimensions less than
or equal to 16, opaque-stippled fill-style with the same size
constraints, and tiled fill-style with bitonal tiles meeting the
same size constraints.

Allen