Date: 	Sun, 31 Dec 1995 05:29:41 -0500
From: amos@nsof.co.il (Amos Shapir)
Message-Id: <9512311029.AA00667@nsof.co.il>
To: rob@plan9.ATt.COM (Rob Pike)
Subject: Re: Do bitblt function codes work?
To: 9fans@cse.psu.edu
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans@cse.psu.edu

In your message of Thu, 21 Dec 1995 08:53:56 GMT you wrote:

> > From: nsof.co.IL!amos (Amos Shapir)

> > On a PC with vga and "out of the box" drivers, the following program
> > generates only 4 distinct images, not 16.  It seems somewhere along
> > the line to/from the bitblt server, the lower two bits of the function
> > codes get hardwired to (binary)10.

> This is correct behavior.  Since you're drawing the line with code 
> 		segment(d, Pt(mid.x, r.min.y), Pt(mid.x, r.max.y), ~0, t);
> using drawing function 0<=t<=15, you might expect 16 different
> results.  But since the source function is the constant ~0, not a general
> value, symmetries fold up and the number of results is reduced.
> The possible answers are 0->0, 0->1, 1->0, and 1->1.  It is not
> the full matrix of possibilities because the source is a single value (1).

> For related information, see the comment in /sys/src/libgnot/gsegment.c.

I have read this comment, and gather that this behavior is a feature;
but I still can't see the rationale behind it.  How can the "value"
parameter be anything but a constant?

I tried all values, and I still can't find any combination that ANDs
the pixel values of two bitmaps; e.g. in the given example, draw just
the part of the segment which falls within the disc.

Happy new year, anyway
	Amos Shapir		Net: amos@nsof.co.il
Paper: nSOF Parallel Software, Ltd.
       Givat-Hashlosha 48800, Israel
Tel: +972 3 9388551   Fax: +972 3 9388552        GEO: 34 55 15 E / 32 05 52 N