(Fwd) Re: FW: Win32 XServer

Kendall Bennett KendallB@scitechsoft.com
Wed Nov 17 21:05:00 GMT 1999

Forwarded message:
From:     Self <KendallB>
To: John Fortin <fortinj@ibm.net>
Subject: Re: FW: Win32 XServer
Date: Wed, 17 Nov 1999 21:04:16 -0800

Hi John,

> >  1. Forget about trying to get XF86_SVGA working direct to hardware
> >     (at least initially; go back and try later if you really wish).
> 	Agreed..

Well that is a relief. It seems to me that Suhaib is hell bent on 
getting XF86_SVGA to run natively under Win32 like it does on OS/2. A 
noble goal but a fruitless one given the bad design of Windows.

> >  2. Don't try to directly program the hardware for graphics, mouse or
> >     keyboard. Instead write the proper OS support functions for the X
> >     event mechanims that talk to the Win32 event mechanism and/or
> >     DirectInput.
> 	Mostly done

Excellent. Sounds like you guys are coming a long way. Can you build 
this stuff without Cygwin, or does it still rely on Cygwin for it's 

> >  3. Start out with an unaccelerated server (you can base it on 
> >    XF86_SVGA since the framework is all there), that uses
> >    DirectDraw to draw directly on the video memory surface. 	
> 	Well, back buffer, then blit to primary.  back buffer is created
> in user memory with a constant pointer so I don't have to lock the
> backing surface...  Only the primary gets locked during the blit. 

The performance of such a server will not be what you would wish, due 
to the fact that all the blitting from system memory to video memory 
will be done in software. Hence the performance hit would be quite 
large (especially if screen->screen and solid fills are done with 
DirectX primitives to the framebuffer).

If you do your locking right, you should have no problem rendering 
directly to the framebuffer. Disregard what the DirectX docs tell you 
about this; unless you are doing blending and need high speed 
framebuffer reads, direct framebuffer writes will be faster.

Also note that if the performance issue is a problem, the XFree86 
server has a 'shadow buffer' mechanism built right in, so you can 
choose to have all drawing done to a system memory buffer at runtime 
(ie: then you can profile which is faster and choose the best one).

> >  5. When the above all works, you can then use the DirectDraw BitBlt
> >     functions to do solid blits, transparent blits and solid color
> >     fills to get some form of acceleration. The blits and color fills
> >     will make a *huge* difference, and at that point you will have a
> >     *very* useable server.
> 	To be done at a later time..

Once you get the basic stuff working, adding screen->screen blits and 
solid fills will be very easy. The performance benefit would also be 
very much worth it.

> >  6. To make things faster, you can use GDI to draw on the primary
> >     surface which would allow you to accelerate text, line drawing
> >     and pattern fills.
> 	Personally, I don't like using the GDI. Since I have a buffer I
> can 	access, I would almost rather use home-grown utilities. 
> However, I am not unwilling to be persuaded... 

The main issue here with using GDI is that you will get access to 
some stuff that can be accelerated in the graphics hardware, that you 
can't access via DirectX services. Using GDI for drawing lines will 
beat the pants of any software line drawing function (assuming you 
are rendering direct to the framebuffer). Text, lines and pattern 
fills will be the things you can speed up big time this way. Other 
stuff you can do in software using XAA...


|   SciTech Software - Building Truly Plug'n'Play Software!     |
| Kendall Bennett          | Email: KendallB@scitechsoft.com    |
| Director of Engineering  | Phone: (530) 894 8400              |
| SciTech Software, Inc.   | Fax  : (530) 894 9069              |
| 505 Wall Street          | ftp  : ftp.scitechsoft.com         |
| Chico, CA 95928, USA     | www  : http://www.scitechsoft.com  |

More information about the Cygwin-xfree mailing list