pn@stc.UUCP (Phil Norris) (09/17/85)
>> Has anyone used the Hitachi HD63484 chip? It appears to be a lot >> more flexible than last generation's 7220s and clones. > It sings, it dances, it plays the flute and harpsichord simultaneously... > and it still can't do RasterOp, so to h**l with it. > Henry Spencer @ U of Toronto Zoology Henry, how about a succinct explanation/definition of rasterops?. Phil Norris
henry@utzoo.UUCP (Henry Spencer) (09/25/85)
> Henry, how about a succinct explanation/definition of rasterops?.
Sorry I've been so long getting back to this. I'm posting it because
there is some chance that non-experts might not know this.
RasterOp (also known as BitBlt) is the basic primitive operation for
modern bit-map raster graphics. It combines a source rectangle of bits
with a destination rectangle of bits, with a number of variations on the
combining function. Using C notation, D=S gives straight copying, D|=S
gives "overprinting", D^=S gives reversible overprinting that is very
useful for things like highlighting and cursors, D&=~S gives erasing, a
few other combinations give useful results. Most RasterOp implementations
also support replication of a "texture" over a rectangle, again potentially
using any of the combining functions. There are various other complexities
that some implementations add: clipping, combining two source rectangles
before working on the destination, etc. Extensions to handle more than
one bit per pixel are straightforward although the combining functions
become much more complicated.
RasterOp, under its old name BitBlt, was invented at Xerox PARC by the
Alto crowd. (BitBlt is "bit block transfer".) It's been copied everywhere.
Most raster workstations incorporate it; many of them have hardware to do
it, or at least to assist the software in doing it. Mind you, said hardware
isn't always as useful as the designers thought, but that's another issue.
Such hardware generally has to be custom chips or custom circuits, since
none of the standard display controllers does anything useful about it.
For a full rundown, see the second edition of Newman&Sproull. The paper
in (I think) the February Software-Practice&Experience by Pike et al is
also very much worth reading.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrydoug@terak.UUCP (Doug Pardee) (09/30/85)
[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
ken@turtlevax.UUCP (Ken Turkowski) (09/30/85)
In article <5988@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> Henry, how about a succinct explanation/definition of rasterops?. > >RasterOp (also known as BitBlt) is the basic primitive operation for >modern bit-map raster graphics. It combines a source rectangle of bits >with a destination rectangle of bits, with a number of variations on the >combining function. Using C notation, D=S gives straight copying, D|=S >gives "overprinting", D^=S gives reversible overprinting that is very >useful for things like highlighting and cursors, D&=~S gives erasing, a >few other combinations give useful results. Most RasterOp implementations >also support replication of a "texture" over a rectangle, again potentially >using any of the combining functions. There are various other complexities >that some implementations add: clipping, combining two source rectangles >before working on the destination, etc. Extensions to handle more than >one bit per pixel are straightforward although the combining functions >become much more complicated. I would like to clarify the application of RasterOp to multi-bit systems. Four functions are readily extended to multi-bit and color systems: OVERWRITE, FLIP, MIX, and ERASE. For overwriting, one simply replaces the destination by the source (D=S). FLIPping is used mostly for cursors and rubber-band lines; its only useful definition is that there is no net change after doing a FLIP with both source and destinations the same. This is usually implemented by performing a generalized exclusive-OR of the source with the destination. MIX is a function that merges the features of the source with the destination. Determination of what constitutes "feature" is simplified if the source is of type "alpha", where alpha is a measure of opacity (somewhere between 0 and 1, inclusive). Otherwise, an alpha mask has to be somehow extracted from the source. The defining equation for each pixel is: D' = (1-alpha) * D + alpha * S = D + alpha * (S - D) where D' is the new value to be plugged into the frame store, D is the old value in the framestore, and S is the value in the source. The multiplication and addition should be appropriately interpreted in the algebra of the color space. Logical-OR, saturating-add, and average are some operations which have been used to implement the MIX function when the source is not alpha. ERASE is defined to be the pseudo-inverse of MIX. Theoretically, the original values in the frame store can be recovered as long as alpha!=1: D = (D' - alpha * S) / (1 - alpha) Quantization may prevent perfect erasure. Some useful convention is used when alpha==0, because the above equation yields 0/0. As Henry indicates above, it is also useful to modulate the above functions with a periodic texture. Any other functions applied to either single- or multi-bit RasterOps are difficult to understand and have limited utility. -- Ken Turkowski @ CADLINC, Menlo Park, CA UUCP: {amd,decwrl,hplabs,seismo,spar}!turtlevax!ken ARPA: turtlevax!ken@DECWRL.ARPA
nather@utastro.UUCP (Ed Nather) (10/01/85)
> I'm posting it because > there is some chance that non-experts might not know this. > Thank you, Henry. ...but if you keep doing things like this, you'll give USENET a good name! -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather@astro.UTEXAS.EDU
mwherman@watcgl.UUCP (Michael W. Herman) (10/02/85)
A good reference for Ken Turkowski's 'MIX' operator is: Thomas Porter and Tom Duff, "Compositing Digital Images", SIGGRAPH '84 Conference Proceedings, pp. 253-259.
henry@utzoo.UUCP (Henry Spencer) (10/04/85)
> 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. If you mean that B+W graphics isn't "true" graphics, come out and say it. Be prepared to defend this argument, since the vast majority of graphic art in books, scientific journals, magazines, etc. etc. is line art -- bit/pixel monochrome, or nearly. So are most hi-res graphics systems, since it's much cheaper to do bit/pixel monochrome *well*, and color or gray scale is really needed only for certain specific applications. (Henceforth I'll use "color" to mean "color or gray scale", and "B+W" to mean "bit/pixel monochrome", since the distinctions within those categories make little difference to the issues here.) I won't dispute your arguments that RasterOp is of limited use for color, because of the problems in defining combining functions, although I suspect there are people out there who would dispute this. What I will dispute is that "true graphics" needs color. Nonsense. Some kinds of graphics need color, notably image processing and synthesis. Other kinds find small amounts of it very handy, notably VLSI design. The rest -- much of the field -- would find it a useful frill, if it was cost-competitive and quality-competitive with B+W... which it's not. Your discussion of the sheer amount of data shovelling needed to do a RasterOp on a multibit image applies to *any* manipulation of such images, not just to RasterOp. This supplies an excellent economic argument for using B+W whenever reasonable and possible, since the volume of data is much smaller and consequently the speed/hardware_dollar ratio is therefore much higher. Printing costs for hardcopy stack up the same way, which is why B+W line art is so prevalent and color is uncommon by comparison. Color everywhere would certainly be nice, but for an awful lot of jobs it simply is not worth the cost. > 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... Unfortunately, these same chips are being hawked as Great Stuff for hi-res monochrome as well, which they aren't. I find no particular indication that the designers specifically intended them for color and only for color, especially since they have no monochrome counterparts. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
doug@terak.UUCP (Doug Pardee) (10/07/85)
> > 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. > > If you mean that B+W graphics isn't "true" graphics, come out and say it. My apologies to Henry and the net -- I placed my quote marks ambiguously. What I meant was not: ... a "true graphics" system but rather: ... a true "graphics system". A system which exists for the express purpose of generating graphics is going to have to be high-resolution color, or it will be run over by the hordes of "microcomputers" which offer a considerable amount of graphics capability as just one of their many features. -- Doug Pardee -- CalComp -- {calcom1,savax,seismo,decvax,ihnp4}!terak!doug
doug@terak.UUCP (Doug Pardee) (10/07/85)
> Unfortunately, these same chips are being hawked as Great Stuff for hi-res > monochrome as well, which they aren't. I find no particular indication > that the designers specifically intended them for color and only for color, > especially since they have no monochrome counterparts. How about this for pure speculation: perhaps the chip manufacturers feel that the potential customers for such a chip (monochrome raster-op) would use a mass-market micro instead (Macintosh, Atari ST, Amiga, etc.). And those micros use in-house developed custom LSI instead of an off-the-shelf graphics controller. Ergo, limited market for a complex and expensive part. Does that make sense? -- Doug Pardee -- CalComp -- {calcom1,savax,seismo,decvax,ihnp4}!terak!doug
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/08/85)
Let's not forget that a significant percentage of the population (mostly male) is at least partially color-blind, so that systems that depend in an essential way on color discrimination will not be suitable for a non-negligible number of potential users. There are also many totally blind computer users/programmers. Although this does not mean that one should avoid producing graphics systems, it does point out that some consideration should be given to providing a second, simpler interface to many applications. Such simpler interfaces are also much better suited for use by other programs (the software tool kit approach).
henry@utzoo.UUCP (Henry Spencer) (10/19/85)
> How about this for pure speculation: perhaps the chip manufacturers > feel that the potential customers for such a chip (monochrome raster-op) > would use a mass-market micro instead... [hence would not use the chips] > ...Does that make sense? This would imply that these people had never seen Suns, Blits, Altos, Stars, Dorados, etc., or never considered that people might want to use said chips to implement such a machine. Sorry, I don't buy it. (I also know, now, of at least one manufacturer which *is* working on RasterOp chips, although they are not yet ready to announce them.) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry