Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: A developer's view of the X fill policy
Message-ID: <8812302033.AA03752@EXPO.LCS.MIT.EDU>
Date: 30 Dec 88 20:33:43 GMT
References: <8812301700.AA00316@adt.uucp>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 51


    Leave the fill algorithm selection up to the
    server.  The ability of a client to select how insidedness is
    determined is of limited use anyway.

You may find it of limited use, but I suspect a developer that drew
a 5-pointed star using either of these fill_rules wanted to be sure
they got it all filled would be rather upset if it came up with a hole.
Are you *sure* you really mean this?

    Just how many people make use of that "feature"?

I don't know (any more than I'm likely to know how many would make
use of your proposed features).

    If you're placing polygons next to each other, can't you make the
    adjustments yourself?

Suppose I want to draw a filled diamond:
	(0, 200), (100, 100), (200, 200), (100, 200)
in one color and then extend it out to a large diamond in another color:
	(100, 100), (200, 0), (400, 200), (200, 400), (100, 200), (200, 200)
(did I get those right?).  I don't want any pixel lit twice.  Can you explain
what "adjustments" I make to achieve that (I really don't want to have to
figure out how to decompose polygons to achieve it).

    Look at it from the other side: how much hardware is there out there
    for which it is NOT painful?

Can you actually name some real hardware that would benefit from your
proposal, i.e. that follow the X rules except for the inside/outside
of the border pixels?  E.g., is it instead more typical of hardware to do
things like use Bresenham outlines for polygon paths, which *isn't* the X
definition of the path.  I'm wondering if you are really only solving part
of your problem, and whether your proposal won't in fact make the server
implementor's life even worse.  (I'm not really sure, I'm asking.)  You
may be making the programmer's life easier, but your original concerns
seemed primarily centered on server performance.

    This is true, but some thought should be put into finding useful
    semantics (or semantics which are useful to the greater audience), not
    just defining them.

We did put thought into the semantics.  We even had the semantics out for
public review.  Of course, maybe those who now care didn't care then,
or didn't know; we did the best we could.  I have heard various complaints
about the fill rule from various people, but it is far from clear to me that
I have heard common threads yet, except "make it implementation dependent",
and I'm not convinced that's "useful to the greater audience".

[Comments from other folks on this proposal would be welcome by me.]