keith@EXPO.LCS.MIT.EDU (Keith Packard) (10/25/90)
> (1) I was told that lines >1 pixel wide would now be rendered in fixed > point. This is only partly true; for instance, using the TWM Icon > Manager, the entries are indeed higlighted with lines rendered in > fixed point (~100 times faster!). However, everthing else I have > tried so far seems to use floating point; I'm refering specifically to > the highlighting of items in a window, when thick lines are drawn > around the box that the cursor has just entered. xman is *definitely* > using floating point routines. Neither twm nor xman control the algorithm which the server uses to draw wide lines. Wide lines have never been rendered using fixed point code (other than on my screen for an afternoon). It is both cheaper and better (i.e. possible to provide exact pixelization) to use an integer algorithm for filling the polygonal portions of the wide lines. Because some of the intermediate values needed to compute the parameters for the polygon filling do not fit in 32bits, the R4 server has a very small amount of floating point code not only to avoid needing a general ~50 bit integer arithmetic package (ok, so call us lazy), but also because floating point arithmetic runs faster on many machines than a simulated ~50 bit integer package would. Older servers (pre R4) used a horrible floating point DDA to walk the polygons. This was both slow and incorrect. For horizontal or vertical lines, the server performs four floating point operations per line. Two integer to floating point conversions and two floating point divides. This is the kind of line drawn by both twm and xman. For diagonal lines, the server performs 5 int to float conversions, 5 multiplies, 1 add, 1 sqrt, 1 divide and 8 float to int conversions. In the cases of xman and twm, I doubt very seriously that you'll be able to detect the presence of floating point arithmetic in the server.