I have started developing the Native GDI server engine for Cygwin/XFree86, after a roughly 7 month lapse during which I worked almost exclusively on the framebuffer-based server that you all use now. The Native GDI server engine aims to translate each X graphics call into GDI graphics calls.
X has several graphics primitives, such as lines, arcs, polylines, etc. All of these shapes can be broken down to requests to draw simple patterns on single lines of bitmaps at a time. The X Server mi code, machine independent (xc/programs/Xserver/mi/), does just that: it breaks down more complex graphics calls into single line graphics operations. mi requires only three functions that depend on the graphics hardware or, in our case, the graphics API with which the server implementer is drawing, namely, FillSpans, SetSpans, and GetSpans. The first milestone in developing the Native GDI server is to implement only the graphics operations in FillSpans, SetSpans, and GetSpans that are required to draw the familiar X background that appears when the server starts up. I had this working 7 months ago, but there were a few problems with the implementation. Seven months ago I did not know how to attach private data structures to graphics contexts (GC) or to pixmaps. Thus, I was using a couple global variables and programming very carefully :) I now have private data structures attached to GCs and pixmaps that allow data such as handles to GDI bitmaps to be associated with GCs and pixmaps. Thus, global variables have been eliminated from the current Native GDI implementation. I had to significantly change FillSpans, SetSpans, and GetSpans because of the change from global variables to private data structures. Somewhere along the way the logic of drawing the X background was broken. I have since repaired most of that logic, causing the "tile" of the background to be generated properly. However, there is a second "tile" that is completely white that is being used to draw the background instead of the familiar hatched tile. The all white tile is surely in error, as it is generated by applying a small all white pattern to a larger pixmap; it doesn't make any sense to perform such a "stipple" fill, as it would be much more efficient to simply do a "solid" fill to create an all white tile. Therefore, I must be somewhere inadvertently switching a bitmap handle, or I might be misreading or miswriting bitmap bits in GetSpans or SetSpans, causing the all white pattern to be created. Of course, it could be something as simple as selecting the wrong brush color in wingc.c/winValidateGC (). I'm out of ideas for now, and I'd appreciate it if some people would start reviewing wingc.c, winfillsp.c, winsetsp.c, and wingetsp.c. Thanks for any help, Harold
