Goals of the test releases

[Harold Hunt <Harold at compasstechnologies dot com>]

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