Re: Goals of the test releases

[Arkadiy Belousov <abelousov at micromuse dot com>]

How about another approach: use the drivers GDI uses? The driver's
nterface has to be documented somewhere...


Harold Hunt wrote:
> 
> 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

-- 
I ask for so little...
And boy, do I get it!