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
