Date: Thu, 28 Sep 1995 15:41:11 +0100
Message-Id: <9509281441.AA02482@rosser.serma.cea.fr>
From: basile.starynkevitch@cea.fr
To: vsta@cisco.com
Subject: bitblt, MADO, display postscript
Content-Length: 3417


Just to add my grain of salt in the discussion concerning graphics
under VSTa :

 (I have several X11 -Xlib- and NeWS programming experience. A long
 time ago, I posted here a description of NeWS; but I never programmed
 any graphic server. My only -small- contribution to
 VSTa is a ext2fs file system server capable of reading Linux
 filesystems. I read a paper about 8 1/2 -the Plan9 windowing
 system). 

I think that a graphic windowing environment should be aimed at
graphics and windows, *not* at terminal emulation (a la xterm). Hence,
graphic applications are *not* console applications, and IMHO they should
*not* have a main() with stdin, stdout, stderr. (graphic window apps are
usually built around an event loop; this is not the case of console
applications). This means that graphic apps are not started by the
POSIX-ian exec (since the start routine should probably not be a main
with argc, argv - perhaps mixed graphic & console applications could
have two "entry points" -main(argc, argv) and another API for graphics).

I believe that a pixel oriented graphics model is just too low
level. In that aspect, the PostScript graphic model (ie almost
arbitrary clipping and coordinates) is the way to go. For instance, a
graphic apps should be easily able to show everything bigger (and this
is a big pain with pixel models such as X11).

Maybe graphic applications should be combinable, like Unix
filters. This mean driving one graphic app by another. I don't know
exactly how this is possible. Perhaps this means define a common
protocol for both graphic events and requests.

Also, windowing could be done very diffently from X11. I'm think that
the policy-free paradigm is probably wrong. We could have a common
toolkit running in the server. (IMHO, widgets dont belong to applications,
but to the window server, as NeWS demonstrated.)

PostScript (eg DPS or NeWS) has several orthogonal features:

** its high level graphic model (arbitrary clipping & coordinates)

** its programmability.

I'm not sure that both are needed. But I do like both of
them. However, I dislike the PostScript (or NeWS) programming
language (mostly because stack programming is too low level). Perhaps
a programmable graphics server should be programmable in a more
structured language (eg a Scheme or ML dialect). Perhaps dynamic
loading of widget code is enough...

I do think that a high level graphic model is the way to go. This
doesn't means postscript (for instance, HP4 are scaled vectorial
printer, but they don't all speak PostScript - perhaps the HPCL5
language could inspire a graphic model).

Just my 10 french centimes (ie 0.10FF, about $0.02).
-- 

----------------------------------------------------------------------
Basile STARYNKEVITCH   ----  Commissariat a l Energie Atomique (civil)
DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France
fax: (33) 1- 69.08.85.68; phone: (33) 1- 69.08.40.66; homephone: (33) 1- 46.65.45.53
email: basile.starynkevitch@cea.fr (redirected to basile@soleil.serma.cea.fr);  
----------------------------------------------------------------------

N.B. Any opinions expressed here are solely mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.

Please cite a **small pertinent part** of my mail in all answers
Veuillez citer une **petite partie pertinente** de mon courrier dans vos reponses