dhuff@AMD-26.HAC.COM (Daryl Huff) (06/03/89)
The frame buffer includes hardware rendering of some of the X defined
graphics primitives such as fonts, lines, and polygon fills.
The fill rule specified by X Windows differs from the fill algorithm
used by our hardware. Our hardware fills the border of the polygon
according to an ideal Bresenham's line drawn between two consecutive
vertices of a polygon while the X Windows fill rule does not. The X
Windows rule appears to truncate the fractional
portion of the pixel value. For example a fill rectangle, as defined by
the X Windows fill rule, will not fill the right column of pixels or the
bottom row of pixels but our hardware rendering device will.
My questions are:
1) Why does X Windows use this fill rule? When you specify a
rectangle to be filled isn't it reasonable to expect that the
entire rectangle will be filled?
2) Is it critical that I somehow force our hardware to use a more
primitive fill algorithm? Does anyone see a problem with just
using the fill algorithm we have implemented in hardware?
3) Why does X specify a fill rule anyway? There are different
circle and line algorithms yet X does not specify which one of
these to use.
Any opinions you may have are welcome.
Daryl Huff
Hughes Aircraft Company (GSG)
dhuff@AMD-26.HAC.COM (Daryl Huff) (06/03/89)
The frame buffer includes hardware rendering of some of the X defined
graphics primitives such as fonts, lines, and polygon fills.
The fill rule specified by X Windows differs from the fill algorithm
used by our hardware. Our hardware fills the border of the polygon
according to an ideal Bresenham's line drawn between two consecutive
vertices of a polygon while the X Windows fill rule does not. The X
Windows rule appears to truncate the fractional
portion of the pixel value. For example a fill rectangle, as defined by
the X Windows fill rule, will not fill the right column of pixels or the
bottom row of pixels but our hardware rendering device will.
My questions are:
1) Why does X Windows use this fill rule? When you specify a
rectangle to be filled isn't it reasonable to expect that the
entire rectangle will be filled?
2) Is it critical that I somehow force our hardware to use a more
primitive fill algorithm? Does anyone see a problem with just
using the fill algorithm we have implemented in hardware?
3) Why does X specify a fill rule anyway? There are different
circle and line algorithms yet X does not specify which one of
these to use.
Any opinions you may have are welcome.
Daryl Huff
Hughes Aircraft Company (GSG)rws@EXPO.LCS.MIT.EDU (06/03/89)
Why does X Windows use this fill rule?
I'm too tired to repeat the arguments. Maybe you can find someone with old
xpert archives. A primary argument is that, whatever the definition is,
primitives laid end-to-end should never cause a pixel to be touched more than
once, and should cause no gaps. I don't know if your definition
satsifies that or not.
When you specify a rectangle to be filled isn't it reasonable to expect
that the entire rectangle will be filled?
Yes, and X does. The problem is simply that we have different notions of
what it means to specify a rectangle. X specifies a width and height for a
rectangle. The area drawn consists of that many pixels across and that many
pixels high. Yours sounds like width+1 and height+1. Whether that's what
you would "expect" probably depends on which school you went to. :-)
2) Is it critical that I somehow force our hardware to use a more
primitive fill algorithm?
I don't know what metric you're using to define "primitive".
Does anyone see a problem with just
using the fill algorithm we have implemented in hardware?
Well, it doesn't conform to the protocol definition.
Why does X specify a fill rule anyway?
So that applications can depend on consistent graphics across platforms.
There are different
circle and line algorithms yet X does not specify which one of
these to use.
Yes, it does, look again. There is a definition for arcs, and for wide lines.