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: <8812302241.AA06577@adt.uucp>
Date: 30 Dec 88 22:41:03 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 66


>    Leave the fill algorithm selection up to the
>    server.

>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?

No, I didn't.  I didn't realize that the fill rules were supposed to
determine how complex polygons should be filled (considering the
description of each in the manual, this is not surprising -- it reads
very much like IBM's _Principles_Of_Operation_).  With this in mind,
perhaps we should make a new GC field, say border_fill, with possible
values FillWithinPath, FillIncludingPath, and FillPartialPath (which
of course would be the current method and should be the default).
This would certainly break a lot more things, but I believe it is a
necessary evil.

>    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).

Consider that I'm in exactly the same place.  How do I create a filled
complex polygon with no points on the path?  Currently it's
virtually impossible.  Is it useful?  For object-oriented graphics it
sure is!  Also, to create a complex polygon with all points on the
path I currently have to do both a fill and a draw, elsewise I get a
polygon with some edges missing.  This causes half of the edges on my
polygon to be "lit twice", by the way, which is exactly the problem
you said you avoid with the current fill technique.  If you're dealing
with objects like I describe, you loose very badly.

>    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?

Silicon Graphics' hardware follows many of the X rules but would have
real problems with the X polygon fill definition.  I think the only
way they'd be able to make use of their hardware currently would be to
cause a fill inside a path and then draw the edges that X would have
filled.  Blech.

Even if it's not possible to make use of hardware and still follow the
X protocol, keep in mind that an awful lot of graphics is done in
object-oriented systems.  It is common to deal with shapes as objects
and to allow them to be bordered, unbordered, or have the border a
different color than the region it contains.  An addition to our
application, FIG and OOPS come to mind.  Interestingly, both FIG and
OOPS bypass almost all of the X high-level graphics, instead using X
as a point-by-point system.  I'm hoping not to have to go to that
level for our application.

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