🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.windows.x.pex
Article #101

Re: Future development of PEX/PHIGS

#101
From: Rich Thomson
Date: Sun, 16 Aug 1992 17:21
51 lines
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!rthomson
References: <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