RE: Goals of the test releases

["Suhaib Siddiqi" <ssiddiqi at inspirepharm dot com>]

>
> Harold,
> 	I agree with your strategy and think that you are
> probably 90% of
> the way there on all the items with the exception of the
> keyboard which
> is somewhat out of your hands. I think someone with little experience
> in DirectX like me would just get in the way.
> 	However, I would be like to help out on implementing
> the X graphic
> primitives via Windows GDI. Could you give me some hints on which
> documentation I should start looking at and what part of the
> code needs
> twiddling with?


You need to study code in xc/programs/Xserver/hw/xwin.

Here is a link for you to read if you want to work on design and adding
features.
Most desirable feature is to add Win32 desktop integration,
so X-desktop disappers, and each X-client opens its own window (aka
multi-widnowing).
The following document explains how to achive it.

http://www.digital.com/DTJL03/DTJL03.HTM

Suhaib


>
> Joel
>
> > -----Original Message-----
> > From: Harold@compasstechnologies.com
> > [mailto:Harold@compasstechnologies.com]
> > Sent: Thursday, November 02, 2000 3:29 PM
> > To: cygwin-xfree@sources.redhat.com
> > Subject: Goals of the test releases
> >
> >
> > Fantastic!
> >
> > It pleases me to hear that test 7 is working on Windows NT machines,
> > finally.
> >
> > I think it would be helpful to state a few of the short-term
> > goals for the
> > test series:
> > 1)  Support screen output on both Windows NT and
> > 	Windows 9X using the least-common denominator
> > 	approach (offscreen frame buffer)
> > 2)  Use a new input scheme that will hopefully work with
> > 	more keyboards, particularly non-English keyboards
> > 3)  Verify that the new input scheme is satisfactory
> > 4)  Display the X server in a window that behaves like a
> > 	normal Windows window
> >
> > I'd say that goals 1 and 2 are nearly done, goal 3 has to be
> > done by the
> > users (I really need feedback from non-English users), and goal 4 is
> > something I was putting off until I knew that goal 1 was at
> > least possible.
> >
> > Here are the longer term goals for the test series:
> > 1)  Use a primary surface buffer on Windows NT
> > 2)  Use an offscreen buffer on Windows 9X
> > 3)  Use a command-line parameter to throttle the blits
> > 	per second on Windows 9X
> > 4)  Produce a stable interim release for all users
> > 5)  Spark interest in the next phase of the project
> >
> > There is only one further goal of the test series that will
> > be implemented
> > after the above nine goals and that is to move away from
> > frame buffers on
> > both platforms.  Moving away from frame buffers requires that
> > we implement
> > roughly 20 graphics functions that do things like drawing
> > lines, circles,
> > arcs, filling rectangles, etc.  A quick investigation will
> > reveal three
> > technologies that seem plausible, if by name only, for
> > implementing the
> > graphics "primitives" as they are called.
> > 1)  DirectDraw
> > 2)  Direct3D
> > 3)  Windows GDI (Graphics Device Interface)
> >
> > A further investigation reveals the following benefits and
> > drawbacks of each
> > technology:
> > 1)  DirectDraw
> >      - No graphics primitives functions (no lines, arcs,
> > rectangles, etc.)
> >      - Only performs bit block transfers
> >      - Not accelerated by the graphics hardware, as you
> > 	have to write directly to the frame buffer
> >      - More suited to games and video playback, as you
> compose a scene
> > 	off-screen, then blit the scene to the primary surface
> >      - We're already using DirectDraw as it was designed to be used
> >      - Offscreen drawing causes a performance hit even when you
> > 	aren't drawing on the X server screen, as the offscreen
> > 	surface has to be blitted to the monitor regardless
> > 	of whether it has changed or not; this severely limits
> > 	the low end of machines that we can support
> > 2)  Direct3D
> >      - No graphics primitives functions (no lines, arcs,
> > rectangles, etc.)
> >      - Only draws points, lines, triangles, triangle fans,
> > and triangle
> > strips
> >      - Implementing graphics primitives would require converting
> > 	arcs, rectangles, and such to triangles; this would involve
> > 	quite a bit of mathematics
> >      - Direct3D doesn't have a concept of filling a rectangle
> > with a color,
> > 	Direct3D thinks of everything in textures; it would get
> > 	pretty bizarre trying to create a texture for every color
> > 3)  Windows GDI
> >      + Graphics primitives functions (lines, arcs, rectangles, etc.)
> >      + Filled shapes (ellipses, rectangles, circles, etc.)
> >      + Pens for drawing lines
> >      + Already has a concept of fonts, and we may be able to adapt
> > 	the standard X fonts to work with Windows
> >      + Windows GDI interacts with the graphics driver, so
> any hardware
> > 	acceleration of primitives can be taken advantage of
> >      - Some GDI primitives don't correspond exactly to their
> > counterpart
> > 	X primitives; extra work we be required for those primitives
> >
> > Obviously, the Windows GDI seems like the way to go to
> implement our X
> > graphics primitives functions.  You may have seen claims that
> > wrapping the
> > Windows GDI for X servers results in poor performance; to
> > that I have to
> > ask, poor performance in relation to what?  You see,
> > emulating X graphics
> > calls on Windows will never be as fast as your Linux box on the same
> > hardware that is able to work with the graphics card more
> > directly; on the
> > other hand, almost anything will be faster than using 20% of
> > your CPU time
> > to blit the offscreen buffer to the primary surface.
> >
> > Well, that concludes the goals that I have for the test releases.
> >
> > Let me hear your ideas and your insights,
> >
> > Harold
> >
>