🚀 go-pugleaf

    But WAIT!  How much of the processor bandwidth will be consumed by 
    Display PostScript?  For that matter, what IS Display PostScript?

    According to what I've heard (no more than third or fourth hand), DSP
    is essentially PostScript with a new binding mechanism and some added
    features for color and raster.  This would indicate to me that it would
    contain some of the limitations of the original PostScript, namely:

	1)  No storage of Paths.  PS does not store more than one path
	    (description of a figure).  To work with multiple paths, one
	    has to write multiple procedures which generate the necessary
	    paths and call the appropriate one whenever one wants to burp
	    out a path.  This applies to transforming a given path multiple
	    times;  you would have to change the global transform matrix and
	    recreate the path multiple times.

	2)  Interpreter overhead.  This includes dictionary lookups,
	    interpreting routines written in DPS (which I would assume
	    is largely unnecessary with a new binding), and such.

	3)  General unfriendliness of the language for developers.

    I am sure there are other consideration here which I am missing but
    others will be sure to catch.  What it boils down to is 1) is Display
    PostScript a convenient imaging model for interactive display graphics,
    2)  does it lend itself to a good development environment, and 3)
    what is its performance?

    Remember, I am writing this note while eating lunch, and tend to have
    trouble focusing and writing clearly with peanut butter stuck to my
    teeth.  Also, I have not seen the DPS specs, and am assuming Adobe did
    not radically modify PostScript for DPS.  

    Any ideas?

    Martin Fox
    Boise, Idaho
    Where all the license plates read "Famous Potatos", even on Porsches.