Path: utzoo!attcan!uunet!samsung!sol.ctr.columbia.edu!cica!iuvax!copper!templon
From: templon@copper.ucs.indiana.edu (jeffrey templon)
Newsgroups: comp.os.minix
Subject: Re: Graphics Lib, GUI, ..., "X Lit"?
Keywords: Minix V1.5, EGA, VGA, Drivers, GUI
Message-ID: <58947@iuvax.cs.indiana.edu>
Date: 17 Sep 90 14:22:40 GMT
References: <69159@sgi.sgi.com> <30331@nigel.ee.udel.edu> <1818@tuvie> <1990Sep14.135606@ecn.purdue.edu> <1990Sep15.133236.15858@stretch.cs.mun.ca> <1819@tuvie>
Sender: news@iuvax.cs.indiana.edu
Organization: Indiana University, Bloomington IN.
Lines: 57


Hi, I was the original fellow to post about MGR so I will describe it a little;
I can't do too much describing since I have only begun to explore it myself.

The MGR system seems to consist of two main parts.  The first part is a
C-language library of functions.  These functions are called from a MGR-aware
program and are used to draw into windows, create windows, cut/paste between
windows, etc.  The second part is the actual MGR program, which receives the
output from the MGR functions and handles drawing the windows, executing the
drawing commands, etc.

The library has functions and macros which only require the C stdio library
to be implemented; no X library, etc. or graphics libraries need to be linked
in with the MGR function library.  When a function is called to create a
window, say, a certain escape sequence followed by some digits is sent to
standard output.

Standard output should be connected to the MGR program itself.  This program
knows what to do when it sees the escape codes.  This part of the system
contains the machine dependency, as it has to know how to draw things onto
the screen.  Thus, MGR would not solve the problems mentioned here about
graphics primitives in the kernel, etc,; it would be oriented more towards
solving the user-interface question.  Having the standard graphics primitives
mentioned before in this discussion would help to make MGR more portable to
different machines running minix.  The mgr-aware programs (ones which make
calls to the MGR library of functions) are already portable, since they
only use the stdio library.

I can give some limited impression of the system.  It seems to be fast; my
experience with it is running with MGR on a Macintosh, connected through a
2400 baud modem to a vax on campus running ultrix 3.1.  I had no trouble
whatsoever compiling and linking the demo MGR-aware programs (a few
clock programs, and some bouncing-box kind of things) on the ultrix vax,
even though the distribution said "sparc".  The Mac side looked to be
unpolished; there was some lossage of characters and not all of the advertised
functions worked; however I got the impression that the Mac MGR program was
beta (there was almost no Mac-specific documentation.)  It would be useful
to hear from someone who has worked with MGR before on a Sun or other machine,
where presumably the program is full-featured.

Mostly it was very fast; I have experience with a program which plots to
VersaTerm on the Mac using TEK4010 graphics codes and it is very slooowww
compared to MGR.

I believe that this same approach is used by X; the server (program which
actually handles drawing the things on the screen) knows about and is
optimized for the hardware, while the client (the program which is doing the
computations) knows essentially nothing about the hardware and sends
brief, standard codes out to the server device when it wants to draw
things.

This is about all I know wrt MGR.  If people are interested, there is a
document describing the C library functions and a MGR man page that I can
post.  The C library function document tells what all the MGR "primitives"
are (drawwindoww, arc, vector, whatever.)

					Jeff Templon