Harold, I'd love to work on this with you, but I'd need info on the GDI calls for windows. I'm gonna look on msdn to see what I can find.
Alan. On Sat, Oct 20, 2001 at 06:09:58PM -0400, Harold Hunt wrote: > 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
