Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!SUN.COM!dshr
From: dshr@SUN.COM (David Rosenthal)
Newsgroups: comp.windows.x
Subject: Re: A developer's view of the X fill policy
Message-ID: <8812312216.AA04339@devnull.sun.com>
Date: 31 Dec 88 19:04:51 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 26

To my memory,  I was the person in the X11 design team that argued most
strongly for leaving the rules implementation-dependent,  in order
to allow the best possible use of available hardware.  I lost the
argument,  and (with the experience of porting the MIT server,
implementing the X11/NeWS server,  and using both X11's pixel semantics
and NeWS's continuous-space semantics) I now think it was best that
I lost the argument.

From the server implementor's point of view,  the problem of adapting
available hardware to ANY pixel-exact semantics specifications is severe.
But filling is no worse than anything else.  So the argument is not about
fills,  it is about whether pixel-exact semantics is appropriate for
all the X drawing operators.

From the client programmer's point of view,  if you are going to have
some drawing semantics pixel-exact,  you must have them all pixel-exact.
Anything else is a nightmare.  When writing client code for X11,  you
need to know exactly which pixels will be hit and which will not.
The sensible alternative to pixel-exact semantics is not leaving
the semantics to the implementors,  but PostScript-style semantics
which specify graphics in a continuous not a discrete space.
A graphics systems that leaves drawing semantics to the implementors is
useless (believe me,  I have been involved in doing this in my mis-spent
youth with GKS).

	David.