This is the mail archive of the cygwin-xfree@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: [Fwd: FW: Win32 XServer]



I noticed a lot of suggestions from Kendall.  My understanding is
John
and Mike had been taking the same approaches.
I also do not accept the idea of GDI.  It is too slow and not good
for
any X server.


As far as DirectX is concerned, I would rather leave this topic to
our
exerts (John and Mike).  I am very confident they would do excellent
job.

To answer about negativity... I forgot to mention also a few private
e-mails addressed to me which suggested XFree86 would not work
on Win32 because it is written for UNIX therefore we would be
wasting our time.  Any how this is off topic now.  Let's get XFree86
working on Windows.  Without Cygwin it certainly would not have been
possible
to port the code in xc/programs/Xserver/hw to Win32.

Suhaib


> >
> > >  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..
> >
> > >
> > >  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
> > >
> > >  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.
> >
> > >  4. Use smart surface locks around the highest level
> primitives
> > >     possible (by smart I mean use a reference counter
> so you can
> > >     avoid a re-lock if the surface was already locked
> by a higher
> > >     level primitive).
> >
> >         Probably not needed.  See above
> > >
> > >  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..
> >
> > >
> > >  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...
> >
> > John
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]