9 Aug
2012
9 Aug
'12
12:46 p.m.
In article <502409A1.7010307 at jwsss.com>,
jim s <jws at jwsss.com> writes:
On 8/9/2012 10:21 AM, Richard wrote:
PostScript works really well as a universal page description language
because each program that want to target a PS printer basically emits
a "preamble" that fills the PS runtime environment with primitives
tailored to the application and then "printing" becomes a traversal of
your in-memory display list, emitting custom PS primitives for each
item in your internal data structure.
PS acts as a universal back end for any application by adapting to the
data structures of the application. This is acceptable because
printing doesn't have to happen at interactive rates and the abstract
ideal of what is to be printed can never, ever, truly be realized by
any real world printer (there is always a resolution limit).
In contrast, for displays programmers expect pixel-perfect results
between platforms and need interactive rates for their applications.
They aren't willing to wait around for the rendering in return for
some abstract ideal. Programs that are graphics intensive have always
been willing to "code for the device" in order to obtain a little more
speed.
Noone complained if your graphics terminal had a funky escape sequence
if it was FAST. Noone complained when SGI introduced a completely new
graphics API library (it wasn't compliant with *any* standard,
official *or* defacto!) because it was FAST. They didn't even care
that the graphics API from SGI *only* ran on SGI hardware and had
weird compatability issues between different models of SGI hardware.
In a modern GPU, it's so crazy fast compared to the CPU at rendering
stuff that for most applications they can embrance an ideal
abstraction and not pay a performance penalty. However, if you're
writing an immersive photorealistic 3D first person shooter, things
are different.
Even there, you'll find a convergence of concepts between the remaining
APIs left standing (Direct3D and OpenGL); the board and chip makers
are differentiating themselves by the broad strokes of their SIMD
architectures, the performance of their individual SIMD units (can you
do double precision floats at no penalty?), speculative execution of
shader stages, advanced pixel culling to get effective increased fill
rate and other innovations like adding more shader stages to the pipeline
(hull, domain and compute shaders in Direct3D are the latest additions,
before that it was the geometry shader) where it makes sense.
I expect the next shader stage to be added to the pipeline is something
that manages the animation of rigged characters for you; currently the
CPU still traverse the bone structure of a rigged character and positions
each bone during an animation cycle, i.e. a walking movement.
No IDE support. If you want to get a feel for
what it's like to
program in NeWS, just start playing around with PostScript. NeWS is a
very thin veneer on top of PS.
I think Sun had some sort of idea that they could
standardize the middle
layer of info for displays and printing. I do recall a term called
Display Postscript, which I think is in the mix somewhere. There was also Openwindows which was replaced by OLWM.
I think
Openwindows is about all you can run on the older sparc1's and IPC IPX
machines because of memory requirements.
OpenWindows is the rendering server (SunView, NeWS, and X11 compliant)
that replaced the SunView server. SunView couldn't handle NeWS or X11
clients, only clients written for SunView. OLWM is a window manager.
The two are very different.
<http://en.wikipedia.org/wiki/OpenWindows>
<http://en.wikipedia.org/wiki/SunView>
<http://en.wikipedia.org/wiki/Olwm>
--
"The Direct3D Graphics Pipeline" free book
<http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>