RE: Architecture of XWin server?

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

Brian,

> I am looking through the XWin porting layer, and I am trying to
> get a handle of
> how the X server was ported.  I initially made the assumption
> that for each
> drawing function, (polyline, polyrectangle, putimage, etc...) you directly
> mapped it to a win32 GDI call.

I started off that way initially.  All of the files, functions, and
intialization procedures are in place in hw/xwin (i.e. wingetspans.c,
winsetspans.c, wingc.c, etc.).  However, I wanted to get a working server
more quickly, so I asked around and found out that using the shadow
framebuffer system would allow us to get a server that worked on Windows
95/98/Me in addition to the originally supported Windows NT/2000.

> As I look through the code, I notice that for most of your
> drawing commands,
> you simply use the machine-independant functions (mi*).  And for
> the polyline
> function, it is a stub, with a simple printout???

Right, according to the porting layer definition, and strategies for porting
guide (both linked to at http://xfree86.cygwin.com/devel/contributing/) the
machine independent funtions (mi*) depend only on wingetspans, winsetspans,
and winfillspans, which are three simple line filling routines.  It doesn't
make much sense to try implementing polygon fills until you can at least
fill a simple line, so writing *spans is the recommended way of starting
out.  I actually had the X background drawing at one point, but I have since
changed the architecture of the NativeGDI engine and lost that
functionality.  (I can't find the particular source snapshot that worked
either).

> My question : How does the XWin port work?

Simple.  All of our drawing is done by Xserver/fb and the updates are
tracked by Xserver/miext/shadow.  Shadow occasionally calls winShadowUpdate*
() (i.e. hw/xwin/winshadddnl.c/winShadowUpdateDDNL ()) which transfers the
updated regions of the offscreen framebuffer to the screen.  The 'fb' layer
draws on modern framebuffers, as opposed to cfb* and mfb which have
old-school assumptions for drawing on old framebuffers.  We simple present
fb with the address of a framebuffer and it draws on it using generic
routines.  Thus, we do not use any graphics hardware optimizations for GDI
drawing functions.

There is some debate over whether translating into GDI functions would be
faster than drawing to a framebuffer and blitting; however, it would
certainly be a better utilization of your hardware, as it would decrease CPU
utilization while using your graphics processor for something other than a
simple memory transfer device.  Unfortunately, we currently lack someone
with enough time and knowledge to finish implementing the NativeGDI engine.
I could contribute more time, but I really need a partner to bounce ideas
off of and to work with.

> Does the cygwin
> server simply work
> like a frame buffer with memory allocated by the GDI?

Yup, that is essentially it.  However, the frame buffer memory is allocated
using three routines: GDI allocated (engine ShadowGDI), DirectDraw allocated
(engine ShadowDD), and user allocated and passed to DirectDraw 4+ (engine
ShadowDDNL).

> Is there a good
> explination anywhere that I can read on how this specific port
> was achieved?

No.  I have intended to put this information into the Contributor's Guide
for some time now.  I haven't yet gotten around to it.

Hope that helps,

Harold