The MSDN GDI documentation is useful, but the following book is essential: Programming Windows, 5th Edition, 1999, Charles Petzold, Microsoft Press, ISBN 1-57231-995-X
Harold > -----Original Message----- > From: Alan Hourihane [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 24, 2001 7:38 AM > To: Harold Hunt > Cc: cygx > Subject: Re: Native GDI Server Development - Call for help > > > 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
