Article View: comp.windows.x.pex
Article #101Re: Future development of PEX/PHIGS
From: Rich Thomson
Date: Sun, 16 Aug 1992 17:21
Date: Sun, 16 Aug 1992 17:21
51 lines
3337 bytes
3337 bytes
In article <5759@m1.cs.man.ac.uk> lilleyc@cs.man.ac.uk (Chris Lilley) writes: [on anti-aliasing] >The Evans&Sutherland implementation has had antialiasing for a while. >The DEC implementation supports it only on harware that supports it. >Both do it as escapes. There is no support for antialiasing in the ISO >standard. There is no explicit support, but that doesn't mean that the renderings are guaranteed to be aliased, either. A PHIGS implementation could render all of its primitives anti-aliased and it wouldn't be in violation of the standard. What is missing are controls for changing the amount of anti-aliasing performed. We provide full anti-aliasing on all line-based primitives (polymarkers, polylines, stroke text) by default. You can turn this off if it is desired via a GSE that we provide. Escapes are a different mechanism used to modify global behavior of a workstation; using a GSE allows hierarchical control of the "aliasing" attribute in a structure. Some line-based primitives in a structure may be aliased while others are anti-aliased, depending on where the GSE is placed in the structure (or issued in immediate-mode). Full support for anti-aliasing could be quickly introduced into PHIGS if all the vendors agreed on a particular format for a GSE data record and registered this record with ISO. Registration is a fairly quick process and doesn't need any voting to take place in order to be accepted. Portability can be maintained if the vendors work cooperatively to support and register such a GSE. If you, as an application programmer or user, desire such support from your vendor, please ask them to support such a cooperative registration. PHIGS can be extended in many ways via registration without having to go to the standards committee and get a full-vote for approval. In this way, vendors can improve and extend upon the basic PHIGS/PHIGS-PLUS definition. The temptation is for each vendor to "go their own way" and provide features only in their implementation not available in other implementations so that they can define themselves as having a competitive edge. This, of course, leads to portability problems. The best way to alleviate those portability concerns is for vendors to register their extensions (thus allowing other vendors to simulate/emulate them if possible) and for users to impress upon vendors how much they care about portability. Companies generally listen to their customers (and if they don't, they deserve what they get I suppose). -- Rich -- Repeal the personal income tax; vote Libertarian in 1992. Disclaimer: I speak for myself, except as noted; Copyright 1992 Rich Thomson UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson Internet: rthomson@dsd.es.com IRC: _Rich_ PEXt Programmer
Technical Details
Message-ID:
<1992Aug16.172124.15631@dsd.es.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!orca!mesa!rthomsonReferences:
<1992Aug13.170434.18221@hsr.no> <5759@m1.cs.man.ac.uk>Show Full Headers
Complete Article Headers
Newsgroups: comp.windows.x.pex Path: arc1-ca.pugleaf.net!sparky!uunet!orca!mesa!rthomson From: rthomson@mesa.dsd.es.com (Rich Thomson) Subject: Re: Future development of PEX/PHIGS Message-ID: <1992Aug16.172124.15631@dsd.es.com> Sender: usenet@dsd.es.com Nntp-Posting-Host: 130.187.85.21 Reply-To: rthomson@dsd.es.com (Rich Thomson) Organization: Design Systems Division, Evans & Sutherland, SLC, UT References: <1992Aug13.170434.18221@hsr.no> <5759@m1.cs.man.ac.uk> Date: Sun, 16 Aug 92 17:21:24 GMT Lines: 51