SECRIST%OAK.SAINET.MFENET@lll-mfe.arpa (12/23/85)
Date: Sun, 22-DEC-1985 21:03 EST To: INFO-MICRO@BRL.Arpa Message-ID: <[OAK.SAINET.MFENET].6BA27F60.008E7E78.SECRIST> Organization: Science Applications Int'l. Corp., Oak Ridge, Tenn. Geographic-Location: 36 01' 42" N, 84 14' 14" W CompuServe-ID: [71636,52] X-VMS-Mail-To: ARPA%"INFO-MICRO@BRL.Arpa" > From: David DiGiacomo <david%sun.uucp@BRL.ARPA> > Subject: Re: 386 Family Products (really registers) > Date: 19 Dec 85 21:25:24 GMT > > ... > ... > typical workstation, those registers would be worthwhile even if > no other code used them. > > (Those with bitblt hardware could try optimizing namei().) Could somebody please tell me what "bitblt" is - I keep seeing it. Much grass. Richard SECRIST%OAK.SAInet.MFEnet@LLL-MFE.Arpa
onn@utcs.uucp (Brian Onn) (12/28/85)
In article <976@brl-tgr.ARPA> SECRIST%OAK.SAINET.MFENET@lll-mfe.arpa writes: > >Could somebody please tell me what "bitblt" is - I keep seeing it. >Much grass. > >Richard >SECRIST%OAK.SAInet.MFEnet@LLL-MFE.Arpa 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. -- ----- Brian A. Onn University of Toronto Computing Services Erindale College. ..!{ihnp4,decvax,harpo,utcsri,{allegra,linus}!utzoo}!utcs!onn "a pessimist feels bad when he feels good, for fear he'll feel worse tomorrow" - The Globe & Mail, Nov. 19, 1985
CHIASSON@drea-xx.arpa (Don Chiasson) (12/30/85)
If you are interested in history, I believe the BLT (BLock Transfer) instruction was first implemented on the DEC-20 and DEC-20 (originally the PDP-6) to transfer a block of words from one location to another. Don Chiasson -------
doug@terak.UUCP (Doug Pardee) (12/31/85)
> Could somebody please tell me what "bitblt" is - I keep seeing it.
Bitblt is a concept used in many bit-mapped graphics systems. It is
an operation which works on rectangular areas of bit-images. The basic
concept is simple:
destination_area = source_area and
destination_area = source_area_1 AND|OR|XOR [NOT] source_area_2
(where black=0 and white=1)
There are a lot of extensions to the basic concept, but you get the
idea.
Bitblt is pretty much restricted to Macintosh-class displays; monochrome
with a resolution of 640x400 or so. The AND|OR|XOR|NOT operators don't
have any particularly obvious meaning in color; what is the result of
(orange AND chartreuse)? At higher resolutions the amount of data to
be processed becomes overwhelming, even with special-purpose hardware
performing the operation. And the amount of memory needed to hold the
various operands also grows with color and high-resolution; to support
bitblt reasonably on a 1024x1024 8-plane color system would require
4 to 8 megabytes of storage just for image-diddling. [A classic speed-
vs-memory tradeoff: if you have special-purpose bitblt hardware in order
to get around the speed problems, you have to use non-virtual memory to
hold the images].
Opinion: bitblt is an endangered species. The popularity of the bitblt
concept was because it was such a simple and powerful approach to the
problems of manipulating bit-images. In color systems bitblt is neither
simple nor powerful; it has all the qualities of a ghastly kludge. With
very few monochrome-only graphics systems being designed these days,
bitblt's days are numbered unless someone can come up with an extension
which will handle color as elegantly as bitblt handled black-and-white.
--
Doug Pardee -- CalComp -- {hardy,savax,seismo,decvax,ihnp4}!terak!dougSECRIST%OAK.SAINET.MFENET@lll-mfe.arpa (01/01/86)
Date: Wed, 1-JAN-1986 14:07 EST To: INFO-MICRO@BRL-VGR.Arpa Message-ID: <[OAK.SAINET.MFENET].D4FA7000.008E8619.SECRIST> Organization: Science Applications Int'l. Corp., Oak Ridge, Tenn. Geographic-Location: 36 01' 42" N, 84 14' 14" W CompuServe-ID: [71636,52] X-VMS-Mail-To: ARPA%"INFO-MICRO@BRL-VGR.Arpa" Thanks to all for the info on the infmaous bitblt. Particular thanks to Brian Onn, John Gilmore, Doug Pardee for their efforts. Richard SECRIST%OAK.SAInet.MFEnet@LLL-MFE.Arpa
henry@utzoo.UUCP (Henry Spencer) (01/04/86)
> Bitblt is pretty much restricted to Macintosh-class displays; monochrome > with a resolution of 640x400 or so. ... At higher resolutions the amount of > data to be processed becomes overwhelming, even with special-purpose hardware > performing the operation. And the amount of memory needed to hold the > various operands also grows... Rubbish, it works just fine at 800x1024 and 1024x1280. And I've seen it work nicely at something like 1700x2000 (with considerable hardware help), although it's hard to buy displays with that kind of resolution. Yes, the memory needs and processing-bandwidth requirements grow, but not beyond the realm of practicality. The Blit does bitblt very quickly indeed at 800x1024 with *no* hardware assist of any kind (its software is, uh, well optimized!). > The AND|OR|XOR|NOT operators don't have any particularly obvious meaning > in color... [and color greatly increases memory needs]... This is true; bitblt isn't the answer to the prayers of the color display. But then, name something that does better! > ...if you have special-purpose bitblt hardware in order to get around the > speed problems, you have to use non-virtual memory to hold the images... Does not follow. There's no reason why bitblt hardware can't use virtual memory the same way the cpu hardware does, although it adds cost and complexity. > Opinion: bitblt is an endangered species. The popularity of the bitblt > concept was because it was such a simple and powerful approach to the > problems of manipulating bit-images. In color systems bitblt is neither > simple nor powerful; it has all the qualities of a ghastly kludge. With > very few monochrome-only graphics systems being designed these days, > bitblt's days are numbered unless someone can come up with an extension > which will handle color as elegantly as bitblt handled black-and-white. Nonsense. This is like saying that monochrome books are an endangered species: the color ones get all the hype, but monochrome still does most of the work. For about the same reason, too: adding color while retaining resolution and clarity greatly increases cost, and the extra expense is justified only for certain specialized situations. Even in the microcomputer world, which is haunted by the ghosts of the TV-as-monitor aberration and the horrendously poor resolution of the early designs, nobody in his right mind voluntarily edits text on a color monitor. Fortunately, machines like the Mac and 520ST are finally bringing decent monochrome into the micro world, although they could do with more resolution. Even in the workstation world, color is not taking over. It's increasingly necessary as an *option* for people like VLSI designers and mechanical engineers, but monochrome still wins decisively on price when color is not an obvious necessity. Bitblt will continue to dominate the monochrome world, which it is eminently well-suited to, while color graphics will continue to be a hodge-podge of kludges, simplistic fudges, and warmed-over vector stuff. (I am speaking of color graphics as opposed to color imaging, the distinction being that color imaging uses at least 8 bits/pixel and preferably 24 or more to give realistic rendering of pictures, while color graphics uses a few bits per pixel in hopes of being useful somehow.) When I asked Rob Pike about color Blits a few years ago, he commented (roughly) "I don't think we know how to use small amounts of color or gray-scale cost-effectively; the money and chips are better spent on more space for monochrome". Still true. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
lotto@talcott.UUCP (Jerry Lotto) (01/05/86)
In article <6264@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes: > TV-as-monitor aberration and the horrendously poor resolution of the early > designs, nobody in his right mind voluntarily edits text on a color monitor. ~> froth, sputter, etc. :-) I have been using the IBM EGA/M combination for a while now and am as happy with it as my Ann Arbor Ambassador. The color is used quite well by various programs, and the programs which use monochromatic modes are quite readable as well. -- Gerald Lotto - Harvard Chemistry Dept. UUCP: {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lhasa!lotto ARPA: lotto@harvard.EDU CSNET: lotto%harvard@csnet-relay
gnu@l5.uucp (John Gilmore) (01/05/86)
In article <956@terak.UUCP>, doug@terak.UUCP (Doug Pardee) writes: > Bitblt is pretty much restricted to Macintosh-class displays; monochrome > with a resolution of 640x400 or so. Hmm, it seems to work great on this Sun with 1152x900 monochrome display, and I've seen it run OK on a Qubix with a 2Kx2K display (driven by a 68010 based Sun). Where's the beer, uh, beef? > The AND|OR|XOR|NOT operators don't > have any particularly obvious meaning in color; what is the result of > (orange AND chartreuse)? This is not quite true. Given that you've set up your color map for it, it can work quite well, e.g. in displaying a chip design using different bit planes for different mask layers. > In color systems bitblt is neither > simple nor powerful; it has all the qualities of a ghastly kludge. With > very few monochrome-only graphics systems being designed these days, > bitblt's days are numbered unless someone can come up with an extension > which will handle color as elegantly as bitblt handled black-and-white. > -- > Doug Pardee -- CalComp -- {hardy,savax,seismo,decvax,ihnp4}!terak!doug I would agree with this if somebody had already come up with the great slices-dices-chops-and-scales paradigm for color systems, but the techniques that make realistic Lucasfilm-style movies are way too slow for ordinary mortals, and the rest mostly still use some form of bitblt.
kds@intelca.UUCP (Ken Shoemaker) (01/06/86)
> > ...if you have special-purpose bitblt hardware in order to get around the > > speed problems, you have to use non-virtual memory to hold the images... > > Does not follow. There's no reason why bitblt hardware can't use virtual > memory the same way the cpu hardware does, although it adds cost and > complexity. Well, if you are willing to make virtual memory hardware that responds in "real time..." I'd think that would be more expensive than just having more memory! > Nonsense. This is like saying that monochrome books are an endangered > species: the color ones get all the hype, but monochrome still does most > of the work. For about the same reason, too: adding color while retaining > resolution and clarity greatly increases cost, and the extra expense is > justified only for certain specialized situations. Oh come on! Just because you haven't thought of any use for something doesn't mean it is useless. I have used a color terminal for normal text editing, and have found it none the lacking. In addition, the use of colors to highlight various things on the screen, whether they be text or graphics, adds another dimension to the display, one that is difficult to get with grey levels or hatch patterns. Also, in at least text applications of color, bitblt can be very easily used. With memory costs on the wane (or at least they were until the government got involved) I don't see the use of color displays going any way but up, even with the more expensive tube. -- remember, if you do it yourself, sooner or later you'll need a bigger hammer Ken Shoemaker, Santa Clara, Ca. {pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds ---the above views are personal.
henry@utzoo.UUCP (Henry Spencer) (01/10/86)
> > ... There's no reason why bitblt hardware can't use virtual memory the > > same way the cpu hardware does, although it adds cost and complexity. > > Well, if you are willing to make virtual memory hardware that responds > in "real time..." I'd think that would be more expensive than just having > more memory! You miss my point: your cpu needs "real time" response too -- a few hundred nanoseconds at the most, usually -- but it has no problem with page faults. The process that was running simply gets suspended until the page is on hand. There's no intrinsic reason why bitblt hardware couldn't do the same thing, although it's not common. > > Nonsense. This is like saying that monochrome books are an endangered > > species: the color ones get all the hype, but monochrome still does most > > of the work. > > Oh come on! Just because you haven't thought of any use for something > doesn't mean it is useless. I have used a color terminal for normal > text editing, and have found it none the lacking. In addition, the use > of colors to highlight various things on the screen, whether they be > text or graphics, adds another dimension to the display, one that is > difficult to get with grey levels or hatch patterns... I didn't say color was useless, just that it's significantly more expensive and usually not worth the price. To match monochrome clarity and resolution, the price tag for the tube and the hardware to drive it is substantial. Especially if you want high resolution, like say 1280x1024. Color monitors with that kind of resolution cost A LOT. Highlighting is indeed useful, although much the same thing can be done with high-resolution monochrome if you work at it. As has been observed before, color is often used as a substitute for detail. I'd rather have the detail, thanks -- it has so many other uses. > With memory costs on the wane (or at least they were until the government > got involved) I don't see the use of color displays going any way but up, > even with the more expensive tube. Memory costs are not the only problem; to update things at the same speed, you also need several times the bitblt bandwidth. And several times the backing-store bandwidth. Those are not as easy to come by as bigger memory. I agree that color use is likely to increase. Color in books is more common than it used to be, too. But most pages of most books are still monochrome, for good sound economic reasons. Given a choice between three monochrome systems, or a single color system with slower display update, I know which I'd pick. Last time I looked, those two choices were about the same price. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry