This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
RE: Native GDI Server Development - Call for help
- To: "Alan Hourihane" <alanh at fairlite dot demon dot co dot uk>
- Subject: RE: Native GDI Server Development - Call for help
- From: "Harold Hunt" <huntharo at msu dot edu>
- Date: Wed, 24 Oct 2001 08:36:58 -0400
- Cc: "cygx" <cygwin-xfree at cygwin dot com>
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