Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!adt.UUCP!madd
From: madd@adt.UUCP (jim frost)
Newsgroups: comp.windows.x
Subject: Re: A developer's view of the X fill policy
Message-ID: <8812301700.AA00316@adt.uucp>
Date: 30 Dec 88 17:00:49 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 72

>I hear a complaint, but I don't hear a proposal.

Add two additional values to the GC field fill_rule, FillWithinPath
and FillIncludingPath.  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.

FillWithinPath will fill all points within the given path and will not
fill points which lie on the path.

FillIncludingPath will fill all points within the given path and will
additionally fill points which lie on the path.

[These are very simple definitions but they should be adequate with
the additional definition of "path", which already exists in the X
protocol.]

Incompatibilities:

None that I can see, although software will require a server which
implements the additional functionality.  Since this is also the case
with extensions, I don't see a particular problem with this.

Benefits:

A lot of software will be easier to write.  Anything that uses the
idea of filled vs unfilled or bordered vs unbordered will take
considerably less time to write.  Currently you have to adjust your
polygons to get this kind of thing to work properly, which is easy
enough to do on a rectangle but is very difficult to do on more
complex polygons.

Many servers will be able to take advantage of special hardware.  It's
my opinion that getting the high-end workstation people on your side
will be good for X in general.

Detriments:

No loss of functionality.  No loss of performance.  Backwards
compatibility problem, but not a serious one.  You can always make use
of the old method if you like.

Comments:

>The X fill semantics are
>designed to allow seamless placement of contiguous polygons without having
>pixels hit more than once.  This is viewed as a feature.

I'm not so sure.  Just how many people make use of that "feature"?  If
you're placing polygons next to each other, can't you make the
adjustments yourself?  This is what I've always done in the past.  I
think this feature has limited use and causes far more problems than
it solves.

>It is true that there is hardware out there for which matching this
>semantics is painful.

Look at it from the other side: how much hardware is there out there
for which it is NOT painful?  I'd say just flat frame buffer stuff,
where you can pick and choose your technique anyway.

>But, the "obvious" alternative of leaving the semantics
>essentially undefined also seems painful, from the developer's
>viewpoint.

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.

Jim Frost
Associative Design Technology
madd@bu-it.bu.edu