RE: Native GDI Server Development - Call for help

["Harold Hunt" <huntharo at msu dot edu>]

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:alanh@fairlite.demon.co.uk]
> 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