Re: Native GDI Server Development - Call for help

[Alan Hourihane <alanh at fairlite dot demon dot co dot uk>]

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