gnu@l5.uucp (John Gilmore) (12/30/85)
In article <1038@utcs.uucp>, onn@utcs.uucp (Brian Onn) writes: > In article <976@brl-tgr.ARPA> SECRIST%OAK.SAINET.MFENET@lll-mfe.arpa writes: > Richard, "bitblt" is a pseudonym for "bit-mapped block transfer", and from > my understanding of it, it is a hardware device capable of moving data that > is defined on bit boundaries from one location in memory to another. It is > used extensively in raster graphics hardware, to optimize line and area > operations. Unfortunately, that's about all I know on this subject. Very close. Bitblt (also known as RasterOp) is an operation that combines two or more bit maps to produce a third. The bit maps are typically rectangular, can be aligned at any bit boundary in memory (or in a frame store) and can usually be a sub-rectangle of a larger one (thus, all the bits are not necessarily contiguous). Typically, these bit matrices are combined with Boolean functions (and, or, xor, and-not, etc). Fancy implementations will merge more than two bit matrices at once (using a Boolean operation with three arguments) or will do funny alignment things to make replicated patterns (like gray stipple patterns) come out looking right. Typical bit maps are: the screen; an icon; a letter of the alphabet; a whole font of characters; a line segment; a block of black or white; a window; a region to be scrolled; a region to be cleared; a cursor (arrow, hourglass, etc). Bitblt was invented for the Alto at Xerox Parc; there it was implemented in microcode. It has been done in hardware, CPU microcode, software, and custom I/O chips since. Modern processor chips (68020, 32016, I believe 80386) implement a one-word subset of bitblt which can read or store bits from the middle of a word anywhere in memory. This can be used in the inner loop of a more complete software bitblt implementation. Most systems that do a lot of bit-mapped graphics provide hardware support of one sort or another for bitblt. Some, like monochrome Suns, AT&T Blits, or the Atari ST, just provide fast access to the frame buffer, a fast CPU, and tight software. There's an excellent tutorial on bit-mapped graphics in the Siggraph tutorials binders from a few years back. Modern graphics textbooks (eg Newman & Sproull _Principles of Interactive Computer Graphics_) also cover it, though not as well from the bitblt point of view.
ian@wcwvax.UUCP (Ian Kemmish) (01/07/86)
There are only 16 functions of two Boolean variables, so it's easy to cater for all possible cases in monochrome. In addition, the fact that historically bitblt has often been done in hardware has meant that there was no extra cost involved in providing all sixteen. By the time we get to mainly-software implementations, history dictates what to implement! In colour, with 8, 16 or 24 bits/pixel, it's clearly ludicrous to try and cater for all eventualities. A lot of people implement their colour screens as multiple bitplanes, so they tend to just allow monochrome bitblts on each plane. This is why colour bitblt often appears to be a no-no. The trick is to define a sensible (but small) set of "useful" operations. Here at WCW, we have done: PAINT (overlay), HIGHLIGHT (invertible), MIX and UNMIX (complementary). Each of these rules can be applied direct between two rasters (except for HIGHLIGHT, which is a unary operation) or via a stencil. This set of rules seems to be enough to do most of the things people need to do with bitmap displays - we have implemented a brush graphics library with arbitrarily shaped, coloured and patterned brushes with no real trouble. We have also mapped these rules into the traditional Boolean functions for operating on monochrome rasters. Footnote: I don't think the Mac actually uses bitblt very much at all. I suspect that Quickdraw calculates the region to fill with a pattern and then fills that region. The reason for my suspicion is that an ellispe drawn with a rectangular brush actually comes out a slightly different shape from a Quickdraw outline oval! ++ You know whose trademarks I've been using ++
frank@sagan.UUCP (Frank Whaley) (01/11/86)
The January '86 IEEE Computer Graphics and Applications contains a
lovely article "Requirements for a VLSI Graphics Processor" by Karl
Guttag, Jerry Van Aken, and Michael Asal of Texas Instruments. They
describe a number of issues for a PixBlt (pixel block transfer)
concept as the color extension of BitBlt, and define both Boolean and
arithmetic operations to be performed on multiple-bit pixels.
I couldn't put it down.
--
...Frank Whaley, MicroPro Product Development
UUCP: {decvax!decwrl | ucbvax}!dual!
{hplabs | glacier}!well!
seismo!lll-crg!
ihnp4!ptsfa!micropro!sagan!frank
ARPA: micropro!sagan!frank@lll-crg.ARPA
"I'm told there are better programs [than WordStar],
but I'm also told there are better alphabets."
--William F. Buckley Jr.