Date: Sat, 30 Sep 1995 12:26:29 -0400
From: Dan Hildebrand <danh@qnx.com>
To: vsta@cisco.com
Subject: Re: bitblt, MADO, display postscript
In-Reply-To: <9509281441.AA02482@rosser.serma.cea.fr>
Message-Id: <Pine.BSD.3.91.950930115319.24877B-100000@qnx.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

In observing the discussion about various windowing technologies for vsta, 
let me provide a few comments about a new GUI we're releasing for QNX 
called Photon.  We've implemented a few GUI's now, and have some experience 
with this.  Perhaps some of the decisions we made will be of benefit in 
your design efforts.  Let me make clear that I'm not trying to sell 
anything here - you guys are into free software, so I doubt you're 
prospective customers in the first place.  :-)  Nonetheless, it's 
refreshing to see a fresh look being applied to GUI's, rather than just 
porting X and being done with it.

This reply is the first of a couple I will make.

On Thu, 28 Sep 1995 basile.starynkevitch@cea.fr wrote:

> Date: Thu, 28 Sep 1995 15:41:11 +0100
> From: basile.starynkevitch@cea.fr
> To: vsta@cisco.com
> Subject: bitblt, MADO, display postscript
> 
> 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).

Nonetheless, it can be useful for launching processes with a standard set
of command line arguments - look at the common command line arguments for
X apps.  Personally, I think the arc/argv stuff is useful at exec time to
let the app take any launch-time overrides for resources it might otherwise
simply load from config files.  After that, the app can fall into an
event loop.
 
> 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).

We created Photon for QNX to solve a whole bunch of these problems.  We 
have a very X/Motif-like API, but the GUI runs in less than 400K and does a 
lot of things that X, any many other GUI's, do not.  Photon is implemented 
as a 40 Kbyte microkernel surround by a team of cooperating processes that 
provide optional services.  As a result, the functionality can be scaled up 
and down just like a microkernel OS by including or excluding various 
processes.

The Photon microkernel implements an "event space" which applications 
populate with regions.  Applications can either emit events from those 
regions, or receive events as they intersect their region in the event 
space.  Regions have masks that determine which classes of events they are 
opaque to, and which they are sensitive to.  All output from applications 
is in the form of draw events into the event space.  Within that event 
space are regions owned by applications.  As events hit those regions, 
other applications can filter those events, generate new ones, clip those 
events, etc.  Input is in the form of mouse and keyboard events generated 
by processes controlling the input hardware and injecting those events from 
regions they own in the event space.  Output is on the form of draw events 
that contain draw lists (which, incidentally, map almost one-to-one to 
postscript drawing commands).  A graphics driver is nothing more than an 
application which owns a region sensitive to draw events.  It receives the 
draw event and renders it on the output device (video frame buffer, 
postscript printer, etc).  Draw events specify the position of the 
primitives in a 64k by 64k space, but the actual rendering of the object 
specified is output-device resolution dependant.  As a result, postscript 
output looks great. :-)
 
> 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.

Exactly - both output (drawing) and input in Photon is in the form of 
events (just travelling in different directions).  By playing tricks with 
regions, you can easily write an app that acts as a transparent color 
filter, for example.  The app would be opaque to draw events, but sensitive 
to them so that the app which owned the region would receive the draw 
event, translate it, and re-emit it perhaps with the colors modified.  For 
example, we have an app that works like a monochrome filter.  Drag it in 
front of a color app and you see a monochrome view through its window.

> 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.)

Been there, done that, and learned from the experience.  :-)

I disagree with the idea of server-implemented widgets.  The problem with a 
server with built-in objects is that if the object inside the server does 
not do what you need, you're stuck.  With a shared-lib based widget 
library, you can always implement what you need from lower level 
primitives.
 
Some tricks:

Since IPC between the processes that make up the GUI form the heart of how 
the GUI works, and since that IPC is network transparent across a QNX LAN, 
you can walk up to a desktop machine with a portable machine in your hand 
connected via a wireless LAN, and drag an application from the desktop 
screen onto your handheld and walk away with it.  We also have "jump 
gates" that allow you to "push" an application through the jump gate so 
that it pops out on another desktop.

Photon draw events are remotely hostable into other GUI's.  For example, 
you can run Phindows (Photon in Windows) on a Windows, NT or OS/2 box and 
open a region in a Photon event space in a QNX node on the LAN somewhere.

The graphical space can span across multiple screens on multiple nodes of a 
LAN.  You can put three machines side by side and map all three screens 
into one contiguous graphical space.  This is done by starting a graphics 
driver process on each machine, each of which own a region in a single 
photon event space.  These regions are tiled, or placed adjacent to each 
other.  Applications see one graphical space and are unaware that the draw 
events are being split across three graphics driver processes which happen 
to be running on different nodes of the LAN.  That graphical space can 
extend across different OS's as well.  For exmaple, on the front cover of 
the next issue of EDN is a photo of a single Photon application stretched 
across the screens 3 computers, running NT, QNX and UNIX with the X Window 
system, respectively.

Due to clever bitmap caching and very optimal draw list encoding, Photon is 
very usable across a 9600 baud link.  Across typical V.32bis modem lines 
it's even better.

Implementing a ditto process (like Carbon Copy for Windows) takes roughly 
40 lines of C, and since only draw lists are being sent back and forth, is 
also very bandwidth efficient.

Performance is good.  You can run Doom inside a window, and opaque drag the 
window around the desktop while it continues to run.  You can even drag 
doom off your desktop onto a desktop across the LAN and performance does 
not appear to suffer (10 Mbit ethernet).

Anyways, I've probably worn out my welcome.  :-)   If you want to see how 
Photon works, look at ftp.qnx.com:/pub/papers/qnx-pen.ps.Z and the 
screenshots at ftp.qnx.com:/usr/free/screenshots.

Dan Hildebrand (danh@qnx.com)               QNX Software Systems, Ltd.
http://www.qnx.com/~danh                    175 Terence Matthews
phone: (613) 591-0931 (voice)               Kanata, Ontario, Canada
       (613) 591-3579 (fax)                 K2M 1W8