Goals of the test releases

[j.j.ita@siep.shell.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? 

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
>