is there an analog of postscript for monitors?: why raster and not vector? - Hardware

This is a discussion on is there an analog of postscript for monitors?: why raster and not vector? - Hardware ; Printers seem to have settled upon a vector way to communicate things to them: the postscript language. I can see this has many advantages plus serves to compress the information transmitted in most cases. Cases that involve geometric primitaves, not ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: is there an analog of postscript for monitors?: why raster and not vector?

  1. is there an analog of postscript for monitors?: why raster and not vector?

    Printers seem to have settled upon a vector way to communicate things to
    them: the postscript language. I can see this has many advantages plus
    serves to compress the information transmitted in most cases. Cases that
    involve geometric primitaves, not photos etc., of course.

    I wonder why "monitors" have not evolved to use a similar language? Most
    monitors (as far as I know) still rely on a raster grid being refreshed at
    intervals.

    Is raster for visual-displays and vector for physical-printouts make sense
    for some fundamental technological reason. Or am I again ignorant, and
    there are vector implementations of languages to communicate with monitors
    too?

    --
    Rahul

  2. Re: is there an analog of postscript for monitors?: why raster andnot vector?

    On Wed, 16 Jul 2008 17:45:47 +0000, Rahul wrote:

    > Printers seem to have settled upon a vector way to communicate things to
    > them: the postscript language. I can see this has many advantages plus
    > serves to compress the information transmitted in most cases. Cases that
    > involve geometric primitaves, not photos etc., of course.


    Normal PostScript is not 'compressed' at all. It is actually plain text
    which you can easily read - well, maybe not so easily - it takes a little
    studying to figure it out.

    >
    > I wonder why "monitors" have not evolved to use a similar language? Most
    > monitors (as far as I know) still rely on a raster grid being refreshed
    > at intervals.


    Primarily because that is how they actually work. Have you ever heard of
    'Disply PostScript'?

    >
    > Is raster for visual-displays and vector for physical-printouts make
    > sense for some fundamental technological reason. Or am I again ignorant,
    > and there are vector implementations of languages to communicate with
    > monitors too?



  3. Re: is there an analog of postscript for monitors?: why raster and not vector?

    ray wrote in news:6e6tflF5lljrU2@mid.individual.net:

    >
    > Primarily because that is how they actually work. Have you ever heard
    > of 'Disply PostScript'?


    Thanks Ray! Actually, I had never heard of that. Just googled the term up.

    >
    > Normal PostScript is not 'compressed' at all. It is actually plain
    > text which you can easily read - well, maybe not so easily - it takes
    > a little studying to figure it out.


    Sorry. I did not mean "compressed" in the usual sense of the term but
    "compressed" vis a vis the alternative of expressing the output as a bitmap
    or similar format. Just wanted to imply that vector formats are less
    information-heavy than raster.

    --
    Rahul

  4. Re: is there an analog of postscript for monitors?: why raster and not vector?

    Rahul writes:

    > Sorry. I did not mean "compressed" in the usual sense of the term but
    > "compressed" vis a vis the alternative of expressing the output as a bitmap
    > or similar format. Just wanted to imply that vector formats are less
    > information-heavy than raster.


    Data-heavy, at least. Consider PostScript an apt description language
    and look up Kolmogorov complexity under information theory. (-: That's
    how compression fits in.

    Mark

  5. Re: is there an analog of postscript for monitors?: why raster andnot vector?

    On Wed, 16 Jul 2008 17:45:47 +0000, Rahul wrote:

    > Printers seem to have settled upon a vector way to communicate things to
    > them: the postscript language. I can see this has many advantages plus
    > serves to compress the information transmitted in most cases. Cases that
    > involve geometric primitaves, not photos etc., of course.


    This is not really correct. All modern printers are of a raster kind.
    Most have a built-in software front-end that takes vector data and
    rasterizes it to become suitable for output.

    > I wonder why "monitors" have not evolved to use a similar language? Most
    > monitors (as far as I know) still rely on a raster grid being refreshed
    > at intervals.


    Displays are raster devices, like printers. At least two vector front-
    ends are available: OpenGL and Direct3D. Rasterization is done by the
    graphic card's GPU.

    --
    Vladimir

  6. Re: is there an analog of postscript for monitors?: why raster and not vector?

    Vladimir Florinski wrote in newsan.2008.07.17.01.53.30
    @ucr.edu:

    > This is not really correct. All modern printers are of a raster kind.
    > Most have a built-in software front-end that takes vector data and
    > rasterizes it to become suitable for output.
    >
    > Displays are raster devices, like printers. At least two vector front-
    > ends are available: OpenGL and Direct3D. Rasterization is done by the
    > graphic card's GPU.
    >



    Thanks Vladimir. True; but doesn't it make sense to rasterize as close to
    the final device as possible? Like printers do. That way the data pipeline
    can be kept as compact as possible most of the way. Opens the possibility
    of using low-bandwidth pipelines like USB and bluetooth. We have USB
    printers but few USB monitors, as yet.

    --
    Rahul

  7. Re: is there an analog of postscript for monitors?: why raster and not vector?

    Rahul wrote:
    > USB printers but few USB monitors, as yet.


    VT220 with a Serial/Bluetooth dongle?

    Chris

  8. Re: is there an analog of postscript for monitors?: why raster andnot vector?

    Rahul wrote:
    > Vladimir Florinski wrote in newsan.2008.07.17.01.53.30
    > @ucr.edu:
    >
    >> This is not really correct. All modern printers are of a raster kind.
    >> Most have a built-in software front-end that takes vector data and
    >> rasterizes it to become suitable for output.
    >>
    >> Displays are raster devices, like printers. At least two vector front-
    >> ends are available: OpenGL and Direct3D. Rasterization is done by the
    >> graphic card's GPU.
    >>

    >
    >
    > Thanks Vladimir. True; but doesn't it make sense to rasterize as close to
    > the final device as possible?


    That would require to put the graphics card in the display, while on
    low-end computers, some of the graphic functionality is performed by the
    "main" CPU, or some of the RAM used by the GPU is part of the standard
    RAM. Kiss bye-bye to inexpensive computers, since it makes the
    full-fledged graphics card mandatory.

    And manufacturers have to offer a very large range of displays,
    considering the possible mix of screen size and GPU power.

    And you would have to worry about the software release used in the
    display.

    And anyway, the bandwidth required between the CPU and the graphics card
    in a modern PC is also very high, around 4Gbytes/sec so moving the card
    to the display may not improve anything.


  9. Re: is there an analog of postscript for monitors?: why raster and not vector?

    On 16 Jul 2008, Rahul wrote:

    > I wonder why "monitors" have not evolved to use a similar language?
    > Most monitors (as far as I know) still rely on a raster grid being
    > refreshed at intervals.


    Old NeXT stations used display postscript. The earliest SGI IRIX
    machines did, too. (IRIX 4 -- I don't think they did after IRIX 5.)
    I don't know about Sun, but some of those from the same era might have
    also used display postscript.


    --
    barutanseijin@gmail.com

  10. Re: is there an analog of postscript for monitors?: why raster andnot vector?

    On Thu, 17 Jul 2008 01:53:30 +0000, Vladimir Florinski wrote:

    > On Wed, 16 Jul 2008 17:45:47 +0000, Rahul wrote:
    >
    >> Printers seem to have settled upon a vector way to communicate things
    >> to them: the postscript language. I can see this has many advantages
    >> plus serves to compress the information transmitted in most cases.
    >> Cases that involve geometric primitaves, not photos etc., of course.

    >
    > This is not really correct. All modern printers are of a raster kind.
    > Most have a built-in software front-end that takes vector data and
    > rasterizes it to become suitable for output.
    >
    >> I wonder why "monitors" have not evolved to use a similar language?
    >> Most monitors (as far as I know) still rely on a raster grid being
    >> refreshed at intervals.

    >
    > Displays are raster devices, like printers. At least two vector front-
    > ends are available: OpenGL and Direct3D. Rasterization is done by the
    > graphic card's GPU.


    Oh, yes. OpenGL - I had forgotten about that. I did have to learn it a few
    years ago, but always considered it a PITA. But it does fill the bill here.

  11. Re: is there an analog of postscript for monitors?: why raster andnot vector?

    On Thu, 17 Jul 2008 02:53:41 +0000, Rahul wrote:

    > Vladimir Florinski wrote in
    > newsan.2008.07.17.01.53.30 @ucr.edu:
    >
    >> This is not really correct. All modern printers are of a raster kind.
    >> Most have a built-in software front-end that takes vector data and
    >> rasterizes it to become suitable for output.
    >>
    >> Displays are raster devices, like printers. At least two vector front-
    >> ends are available: OpenGL and Direct3D. Rasterization is done by the
    >> graphic card's GPU.
    >>
    >>

    >
    > Thanks Vladimir. True; but doesn't it make sense to rasterize as close
    > to the final device as possible? Like printers do. That way the data
    > pipeline can be kept as compact as possible most of the way. Opens the
    > possibility of using low-bandwidth pipelines like USB and bluetooth. We
    > have USB printers but few USB monitors, as yet.


    It has somewhat to do with speed. It does not matter if the printer takes
    a few seconds to process and print a document - most folks want pretty
    much instant updates on their video device.

  12. Re: is there an analog of postscript for monitors?: why raster and not vector?

    ray writes:

    > It has somewhat to do with speed. It does not matter if the printer takes
    > a few seconds to process and print a document - most folks want pretty
    > much instant updates on their video device.


    Mmmm. I'm probably an atypical user in that you really could get much of
    my display use into a low-bandwidth stream with higher primitives - I
    don't play computer games or use any fast fancy graphics or large
    bitmaps anywhere, except maybe in using xplanet which I don't mind if
    it's slow - but even I watch video sometimes, and even if you can squirt
    various MPEG formats at the monitor and have it decode them at its end,
    what do you do about new or rare codecs? For instance, say I have a
    Theora stream, is there some general purpose computer with fast
    processor in the monitor that I can squirt a new driver at so it can
    decode the stream? (Or can you implement real-time codec decoders on
    FPGAs and then do JTAG-over-USB to reprogram an FPGA in the monitor or
    something?) I suspect that upgrade capability to do things like cope
    with many different codecs could make a USB monitor much more expensive
    and error-prone. Basically, I can imagine that you might want to be able
    to redefine the set of more-compact-than-raster description languages it
    understands and quickly expands to raster, and that might make things
    too unwieldly.

    Mark

  13. Re: is there an analog of postscript for monitors?: why raster and not vector?

    Rahul wrote:
    > Vladimir Florinski wrote in newsan.2008.07.17.01.53.30
    > @ucr.edu:
    >
    >> This is not really correct. All modern printers are of a raster kind.
    >> Most have a built-in software front-end that takes vector data and
    >> rasterizes it to become suitable for output.
    >>
    >> Displays are raster devices, like printers. At least two vector front-
    >> ends are available: OpenGL and Direct3D. Rasterization is done by the
    >> graphic card's GPU.
    >>

    >
    >
    > Thanks Vladimir. True; but doesn't it make sense to rasterize as close to
    > the final device as possible? Like printers do. That way the data pipeline
    > can be kept as compact as possible most of the way. Opens the possibility
    > of using low-bandwidth pipelines like USB and bluetooth. We have USB
    > printers but few USB monitors, as yet.
    >

    But how long does it take for the printer to produce each image?
    A monitor has to produce an image perhaps 70 or more times per
    _second_. The bandwith requirements are a great deal larger for a
    monitor than for the average printer.

    Jerry


  14. Re: is there an analog of postscript for monitors?: why raster and not vector?

    >>>>> "Barutan" == Barutan Seijin writes:

    Barutan> On 16 Jul 2008, Rahul wrote:
    >> I wonder why "monitors" have not evolved to use a similar
    >> language?


    You mean Tektronix terminals? They were an ingenious product -- using
    the CRT screen as "memory".

    http://en.wikipedia.org/wiki/Tektronix_4014

    The control language is not as sophisticated as the Postscript
    language. The computer uses a set of ESC sequences (just like ANSI
    sequences) to send very simple commands to the terminal, so as to tell
    the latter to draw lines on the screen. As a matter of fact, 'xterm'
    has a Tektronix emulation mode.



    >> Most monitors (as far as I know) still rely on a raster grid
    >> being refreshed at intervals.


    According to the Wikipedia page quoted above, most *graphical*
    monitors older than the Tektronix 4014 used vector graphics. I cannot
    verify this, but it sounds reasonable: a raster-based graphics display
    requires a lot (by the stands of those day) of RAM to serve as the
    frame buffer, and RAM were 10^n times more expensive they than are
    nowadays. So, raster-based graphics was impractical.


    Barutan> Old NeXT stations used display postscript. The earliest
    Barutan> SGI IRIX machines did, too. (IRIX 4 -- I don't think
    Barutan> they did after IRIX 5.) I don't know about Sun, but some
    Barutan> of those from the same era might have also used display
    Barutan> postscript.

    I don't think Sun has ever adopted DPS.

    Given the popularity of Postscript in unix and printing, I can't see
    why DPS would be technically inappropriate for X. Maybe, the failure
    of DPS is due to marketing and licensing issues. (I really wished to
    see an X11 extension to support PS-based vector graphics, which could
    be implemented using Ghostscript!)

    See http://en.wikipedia.org/wiki/Display_postscript


    Recently, some open-source developers have developed libraries for
    rendering SVG (a W3C recommendation), and Gnome/KDE3 developers are
    gradually replacing their bitmap-based icons with vector-graphics
    ones. Although SVG isn't Postscript, its graphics model as well as
    available primitives are very similar to Postscript. It's not a
    programming language, though.



    --
    Lee Sau Dan u ~{@nJX6X~}

    E-mail: danlee@informatik.uni-freiburg.de
    Home page: http://www.informatik.uni-freiburg.de/~danlee

  15. Re: is there an analog of postscript for monitors?: why raster and not vector?


    >
    > You mean Tektronix terminals?
    >
    > They were an ingenious product -- using the CRT screen as "memory".
    >
    > http://en.wikipedia.org/wiki/Tektronix_4014


    What a blast from the past !

    I spent at least a bazillion and 42 hours
    using one of these back in the mid-1970s
    at VPI & SU ....

    Connected to a dual IBM 168 mainframe via 1200 baud dial-up
    and using CMS ( Conversational Monitory System ) as a shell ....

    Using a fortran-based plot package called EZJoy or PureJoy
    from one of the New York universities, maybe Stoney Brooke,
    I could plot a series of 3d surface rotatiions and save them
    into a file in a manner very similar to the way we now pipe
    console output or screen sessions to a file ....

    spool console start to some.file

    Then you could re-play the console session
    just by issuing a type some.file command
    faking step-wise animation without having
    to re-process all the graphic commands
    using the cpu and slow dial-up line ....


    --
    Stanley C. Kitching
    Human Being
    Phoenix, Arizona


+ Reply to Thread