dhuff@AMD-26.HAC.COM (Daryl Huff) (06/17/89)
I am in the process of developing a plane for porting the X11R3 server
to a new graphics engine and need a bit of help in two areas. (I'm fairly
new to X Windows as well as expert so, sorry if these questions have been
covered before.)
The first area I am having trouble in is estimating the memory requirements
of the X Windows server. I am trying to assess the feasibility of porting
X server to a system without a disk. Therefore I need to get an idea of
the amount of main memory that would be required in this type of a system.
I realize the answer to this question is dependent
on many things including the number of windows open, the number of fonts
loaded, where I store my pixmaps (main memory or in the frame buffers), etc.
The second question is about the line alorithm of the X server. The
X protocol specification defines a line to be a filled rectangle with
vertices at:
[x1-(w*sn/2),y1+(w*cs/2)],[x1+(w*sn/2),y1-(w*cs/2)],
[x2-(w*sn/2),y2+(w*cs/2)],[x2+(w*sn/2),y2-(w*cs/2)]
using the fill algorithm also defined in the protocol spec. The problem
I have is that in the "Strategies for Porting the X v11 Sample Server",
dated March 1, 1988, section 2.4.14.2. (Second Round Optimizations),
describes how to optimize the line drawing performance of X by implementing
a Bresenham edge walker. First, I don't believe that line drawn with
Bresenham's algorithm conforms to the X definition of a line. Second, I
am confused by the reference to a need for multiplication and
division in implementing Bresenham's algorithm since the algorithm was
developed to avoid the need for multiplication and division when solving
for a line.
Any help in these two areas would be appreciated.
Daryl Huff
Hughes Aircraft Co.keith@EXPO.LCS.MIT.EDU (06/17/89)
(The first question is not answerable in closed form) >The second question is about the line alorithm of the X server. The >X protocol specification defines a line to be a filled rectangle with >vertices at: > [x1-(w*sn/2),y1+(w*cs/2)],[x1+(w*sn/2),y1-(w*cs/2)], > [x2-(w*sn/2),y2+(w*cs/2)],[x2+(w*sn/2),y2-(w*cs/2)] >using the fill algorithm also defined in the protocol spec. The problem >I have is that in the "Strategies for Porting the X v11 Sample Server", >dated March 1, 1988, section 2.4.14.2. (Second Round Optimizations), >describes how to optimize the line drawing performance of X by implementing >a Bresenham edge walker. First, I don't believe that line drawn with >Bresenham's algorithm conforms to the X definition of a line. Second, I >am confused by the reference to a need for multiplication and >division in implementing Bresenham's algorithm since the algorithm was >developed to avoid the need for multiplication and division The strategies document was refering mostly to zero-width lines which are not restricted by the above equations for pixelization -- a Bresenham zero-width line is quite acceptable; the mfb sample ddx layer uses one. The multiplication/division in the mfb implementation are required to wind the algorithm past any clipped regions of the line as even zero-width lines are supposed to draw the same pixels in the presence of clipping. You could step the algorithm past the clipped region and simply avoid the pixelization portions (this actually works quite well for short lines).
rws@EXPO.LCS.MIT.EDU (06/17/89)
Keith misspoke; the strategies document really is referring to wide lines, and the comments in mifpolycon.c confirm this. The Bresenham stuff should be ripped out (maintaining the Strategies document hasn't been high on our list, nor has cleaning up garbage comments in the code). The problem is that the original sample implementation was done under somewhat chaotic conditions, and the translation of final protocol semantics to source code did not always quite make it. This is a case in point.