Subject: Re: Graphical M*'s

From: [email-masked] (H. Peter Anvin)
Date: Thu, 11 Mar 1993 21:51:22 -0800

You write:
> 
> A good point.  But...
> 
> I actually don't have any hard data about speed of Display PostScript
> implementations.  (Someone who uses NeXT machines would be a big help here; I
> can ask several such users I know.)  However, I'm presuming that this is to be
> used to display simple pictures, not to render text.  Assuming that the
> pictures really are fairly simple (no computed fractals or whatever), then
> they're mostly either bitmaps or polygon fills.  In either case, the majority
> of the time would presumably be spent in the actual rendering (which would be
> required of any rendering system), rather than in interpretive overhead (which
> In short, my presumption is that most of the "programs" would be only a few
> lines, ignoring bitmap data, and probably not have heavy-duty loops in them.
> Thus, unless you're talking about a badly-written interpreter, there's no
> reason why PostScript should be particularly slower than anything else.  The
> nature of the coordinate system _does_ tend to presume you can do real
> arithmetic fairly quickly, but I'd argue that this is required anyway, since
> you can't assume that everyone's client has the same coordinate system (this
> would be tantamount to assuming they all have the same size and resolution
> screen, which can't be true).
> 
> Also, you're not really talking real-time animation here anyway, unless again
> it's being done by the client.  After all, text-only servers are pretty lagged
> now!
> 
> So the basic issue here is, given what we'd expect to be displaying (pictures,
> not finely-rendered high-resolution text), would a good PostScript interpreter
> have to be much (or any) slower than something else which has the necessarily
> flexibility?  If so, why?  I'm certainly willing to be convinced, but I can't
> think of any compelling arguments at the moment why this must be so.
> 

PostScript is slow.  It is pretty tolerable on a NeXT; I don't exactly
know what they are doing, but the lag is noticeable.  On an RS/6000 it
takes about 5 seconds to write the copyright notice in DPS text.

I simply think Display PostScript is overkill.  I think we could make
do with 32-bit integer arithmetric using a pretty straightforward
pixelated coordinate system.  That should be prefectly adequate on a
display terminal (while of course it is totally inadequate for high
quality printed output).

We should maybe make a mailing list to discuss this?

	/hpa

-- 
INTERNET:  [email-masked]   TALK:      [email-masked]
BITNET:    HPA@NUACC     IBMNET:    16331@IBMX400
HAM RADIO: N9ITP         NeXTMAIL:  [email-masked]
#include <sigvirus.h>

---

From: [email-masked]
Date: Sun, 28 Feb 1993 07:11:12 -0800

>display terminal (while of course it is totally inadequate for high

Display PostScript is certainly overkill. But the problems we're encountering
are not new... Display PostScript is one of the most recent in a long line
of display languages. The one I'm working with is Tektronix, and I think it's
a good choice. I don't think anyone should be creating new graphical standards
without a _real_ good reason, especially if they hope people of diverse
computational backgrounds to utilize the tools you build. This is why I like
tek. There are free or cheap emulators available for just about anything,
it's designed for low bandwidth links, it's resolution independant, color,
and accepts input from keyboard or mouse/trackball driven crosshairs.

My plan right now is to take the basic tek work I've done, which already gives
a nice animated interface to MOO, and start extending it, so people running
a client that supports my superset of tek can take advantage of the third
dimension, bitmaps, and sound. But since we've even got ASCII equivalents of
more or less everything we've done, people using an Indigo could mix with and
render people who're on teletypes.
  -James/Minstrel-

/-----------------------------------------------------------------------------\
| James Powell - Programmer/Analyst - Special Projects - [email-masked]   |
\-----------------------------------------------------------------------------/