Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!think!ames!ptsfa!ihnp4!chinet!steinmetz!jesup
From: jesup@steinmetz.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: New IBMs?  Amiga runs circles...
Message-ID: <1444@steinmetz.steinmetz.UUCP>
Date: Tue, 14-Apr-87 16:19:14 EST
Article-I.D.: steinmet.1444
Posted: Tue Apr 14 16:19:14 1987
Date-Received: Fri, 17-Apr-87 03:23:45 EST
References: <1825@vax135.UUCP> <160005@wsucshp.UUCP>
Reply-To: jesup@kbsvax.steinmetz.UUCP (Randell Jesup)
Organization: General Electric CRD, Schenectady, NY
Lines: 65

In article <160005@wsucshp.UUCP> kinner@wsucshp.UUCP (Bill Kinnersley ) writes:
[Someone wrote this, I don't know who.  REJ]
>     I can envision at a future time somebody allocating a background
>     bitmap, rendering (and filling) the ellipse in the background by the 
>     most efficient method available, then blitting (ClipBlitTransparent?)
>     the resultant ellipse into the target area.  I would assume that the
>     result would be faster than the writepixel-per-dot than is now done?

	This is already possible, in two different ways:
1.  Use AreaEllipse and a TmpRas to do a filled Ellipse using current
  drawing modes.  Internally, this writes an ellipse into the TmpRas (I
  presume using DrawEllipse, and thus WritePixel.  Not too bad, though,
  because no clipping need be done.  Then it blits the AreaPtrn into the
  destination using the area fill mode of the blitter.  Note that the
  drawing modes DO apply, so you can do things like COMPLEMENT, etc.
  Minor bug: AreaEllipse won't draw an outline in the AOlPen color.

2.  Draw the Ellipse in a private RastPort, Flood fill it, (or use your own
  fill/draw routines), then use ClipBlit (or if it's in a BitMap, use
  BltBitMapRastPort) to blit it into the destination.

>Great! Then maybe someone can teach Intuition to do its window rendering
>into portholes.  (Could bols ewhacs give us a demo of this sometime?)

	This is a seperate question, having to do with the layers library.
It would be nice to be able to specify the clipping for a RastPort by a
BitMap, as well as with rectangular bounds.  Essentially, all blits to the
RastPort would use 3 sources, not the more common 2.  The equation for
the Blit would be (assuming a is the mask, b is the source, c is the second
source (usually the same as the destination), and the result goes in d):

	D = (A)(old_equation) + (NA)(C)
Where old equation was something like:
	D = (B)(NC) + (NB)(C) where (NX) == not X  ("Cookie Cut" blit, 0x60)
This would mean

	Most standard user Blits use two sources, B & C, with B = the source
and C = the Dest.  (Ex: ClipBlit, BltBitMapRastPort, etc). 
	Any Blits that used all three sources, or that didn't use the 
destination as a source, would have to broken into two Blits.
	All of this could be hidden from the user, as are the multiple blits
used for ClipBlit and BltBitMapRastPort, used to handle the rectangular
Clipping regions.  It might even be faster, as Blits might not have to be
Clipped by code.
	There are some drawbacks, though:  Extensive rewrite of the layers
library, and calls like ClipBlit.  Potentially large memory use for rastports
using this feature (at least 1 full extra bit-plane.)  Potential problems
dealing with the rewrite of code (probably won't always be totally
transparent, though we can try.)  It all depends on whether it can be hidden
in the layers library.  In any case, it shouldn't effect old code at all.

	I definitely think it's worth investigating.  I've been trying to find
ways to do things like this for a while, and the closest I've come without
playing with the blitter directly or useing several levels of indirection is
the new call BltMaskBitMapRastPort, in which the source must be a bitmap (as
opposed to a rastport, ala ClipBlit), and the mask must be the size of the
source BitMap.  If I want to Clip bitmap blits to rastports, it'll do, but
it's not the same as what the layers library does.

	Any Comments or better ideas?  Better yet, any volunteers?
	Will it work at all?

	Randell Jesup
	jesup@steinmetz.uucp (seismo!rochester!steinmetz!jesup)
	jesup@ge-crd.arpa