(Fwd) Re: FW: Win32 XServer

[Suhaib Siddiqi]

> 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.

That what Mike and John refered to as negativve attitude.

As I suggested that instead of keep telling volunteer FRUITLESS
efforts, why not contribute.

If I would not have taken a "hell bent on getting XF86_SVGA to run
on Win32" atitude, XFree86 porting project would never had been
started.

My concept of doing a XF86 port along the line of Holger's approach
might be totally wrong, but someone needs to prove me wrong by
contributing, not by negative comments.

>
> > >  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
> Unix'isms?


Please note the name of project "CYGWIN-XFREE".
Not sure why you are so much opposed to Cygwin.  It is a marvelous
tool.

Now even Exceed supports Cygwin for X developers Kit (Exceed XDK).

I prefer to take a step by step approach.  Non-cygwin support MIGHT
be added later on.  I have already supplied you patches for
libraries and clients for MSVC.  This should allow developers to X
develop products without using cygwin1.dll.



>
> > >  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).


Mike's idea is to have an unaccelerated server working first.  This
would be a test-case and would allow us to make further progress.
I agree with Mike.  It is a very approach.

>
> 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.
>


We would certainly look into it, but first have at least one
X-server working.

Suhaib


> > >  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...
>
> Regards,
>
> +---------------------------------------------------------------+
> |   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  |
> +---------------------------------------------------------------+
>