Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site terak.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!hao!noao!terak!doug
From: doug@terak.UUCP (Doug Pardee)
Newsgroups: net.graphics
Subject: Re: rasterops (an alternate view)
Message-ID: <741@terak.UUCP>
Date: Mon, 30-Sep-85 13:08:50 EDT
Article-I.D.: terak.741
Posted: Mon Sep 30 13:08:50 1985
Date-Received: Fri, 4-Oct-85 06:05:55 EDT
References: <588@stc-b.stc.UUCP> <5988@utzoo.UUCP>
Organization: Calcomp Display Products Division, Scottsdale, AZ, USA
Lines: 49

[Note: I am not a disinterested party in this subject, but I'm not
at liberty to discuss my connection right now]

Raster-ops (aka bit-blt) is a fine paradigm for systems like the
Macintosh -- medium resolution black-and-white, basically text with
some intermixed graphics.  But it is inadequate for any system that
would call itself a true "graphics" system.

As Henry noted:

> Extensions to handle more than
> one bit per pixel are straightforward although the combining functions
> become much more complicated.

The combining functions are the very *heart* of raster-ops.  The added
complexity of those functions tends to remove any advantage that
raster-ops have over more conventional techniques.

But there is more to this multiple-bit-per-pixel (color or gray scale)
issue.  The concept of raster-ops is based on the notion that you have
some huge quantity of memory, a small portion of which is displayed on
the screen.  In a color type system, the amount of memory required for
the "working areas" goes up in proportion to the number of bits per
pixel.  And the processing time required goes up just as fast.

Complicating the issue:  going to high-res (1024x1024 pixels or so)
places even further demands on memory and processing power.  In the
end, a system with 1024x1024, 8-bit color would require a few
megabytes of memory just for graphics working areas.

And the amount of processing necessary to manipulate that data would be
enormous.  Simply copying one screen's worth from the working area to
the display area requires moving a megabyte of data.  Assuming
conventional DRAMs, 330ns full cycle time, organized 16 bits wide, this
would take a third of a second even if the display controller didn't
add any overhead.

Furthermore, the manipulative capabilities of raster-ops are limited,
when used for graphics.  Zoom is limited to pixel replication.  Rotation
is limited to 180 degrees (and 90 and 270 if 1:1 pixels are used).  Pick
is, well, nearly impossible.

I don't think that one should be too surprised that the new-generation
graphics controller chips, intended for use in high-resolution,
multiple-pixels-per-plane applications, would not include a full set
of raster-ops.  It isn't easy to do, and few systems could afford to
have huge graphics memories while delivering poor graphics performance.
-- 
Doug Pardee -- CalComp -- {calcom1,savax,seismo,decvax,ihnp4}!terak!doug


Brought to you by Super Global Mega Corp .com