Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site l5.uucp Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!pyramid!ut-sally!mordor!lll-crg!l5!gnu From: gnu@l5.uucp (John Gilmore) Newsgroups: net.micro Subject: Re: What is \"bitblt\" ? Message-ID: <398@l5.uucp> Date: Sun, 5-Jan-86 05:33:42 EST Article-I.D.: l5.398 Posted: Sun Jan 5 05:33:42 1986 Date-Received: Mon, 6-Jan-86 03:31:24 EST References: <976@brl-tgr.ARPA> <956@terak.UUCP> Organization: Nebula Consultants in San Francisco Lines: 28 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.