Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!rosie!aozer
From: aozer@next.com (Ali Ozer)
Newsgroups: comp.sys.next
Subject: Re: graphics portability between ns and ns-color
Message-ID: <898@rosie.NeXT.COM>
Date: 6 Jun 91 01:12:16 GMT
References: <9106050533.AA20158@nextasy2.eecs.wsu.edu> <1669@toaster.SFSU.EDU> <1991Jun5.091018.21988@agate.berkeley.edu>
Sender: news@NeXT.COM
Organization: Next Computer, Inc.
Lines: 75
Nntp-Posting-Host: twinpeaks.next.com

In article <1991Jun5.091018.21988@agate.berkeley.edu> Izumi Ohzawa writes:
>[1] NeXT goofed.
>[2] Pixar goofed.
>[3] It's a feature of NeXT alpha channel.
>My guess is [3].

The bottom line with black alpha vs white alpha is: Do not show alpha on the
screen; what you get is system dependent. I tend to think of drawing alpha 
into a window as cutting a hole in that window, and what you see is the 
inside of the back of your monitor. (Of course some might argue that
this should cause whatever is under this window (for instance, other windows,
or the Workspace background) to show through... Well, yeah, that's a neat 
idea, but NeXTstep does not do non-rectangular windows.)

So when do you use alpha? When creating images which will be layered on top
of each other, for instance. You might either read a TIFF with transparency,
or create an NXImage, clear it to transparent and draw some stuff in it.
Then these images would be layered on top of some background using 
operators such as SOVER, which causes the alpha bits of the layered image 
to determine the color of the pixels that show up on the screen without 
actually putting the alpha on the screen.

Going back to the original message:

David Watola writes:
>I have a custom view class that draws one of a set of NXImages cached as
>NXEPSImageReps.  The drawing routine for this custom view only does one 
>thing-- it does a
>
>  [theNXImage drawRepresentation:theNXEPSImageRep inRect:&theBounds]
>
>which draws a properly scaled version of that image in the view.  TFM
>says that drawRepresentation:inRect: fills in the view with the background
>color, then draws the image.

Here's what the documentation says about drawRepresentation:inRect: :
 The NXImage uses this method to cache its representations and to print them.
 By overriding it in a subclass, you can change how representations appear in 
 the cache, and thus how they'll appear when composited.  For example, you
 could scale or rotate the coordinate system, then send a message to super
 to perform this version of the method.

This method is here only for subclassers; it should not be used by other
objects.  It is the method an NXImage uses to cache one of its 
representations in its very own internal caches. The reason you end up
getting alpha on the screen is because NXImage clears the cache to transparent
(the default background color) before drawing the EPS file in it; thus, in
your case, because you are drawing in your view, the alpha goes
directly to the view.

The correct ways to draw EPS reps include:

1. If you don't want to cache it, then simply create an instance of
   NXEPSImageRep and use draw or drawIn: to draw it:

   theEPSImageRep = [[NXEPSImageRep alloc] initFromFile:"BugsBunny.eps"];
	...
   // later, in drawSelf:: :

   [theEPSImageRep drawIn:&bounds];

2. If you want to cache the EPS (which might be a nice idea if you'll draw
   it many times, or the view is destined to be in a ScrollView), then
   create an NXImage from the EPS file and use composite:toPoint: to draw it:

   theEPSImage = [[NXImage alloc] initFromFile:"BugsBunny.eps"];
	...
   // later, in drawSelf:: :

   PSsetgray (NX_WHITE);	// These two lines might not be
   NXRectFill (&bounds);	// necessary or might be different...
   [theEPSImage composite:NX_SOVER toPoint:&bounds.origin];


Ali, Ali_Ozer@NeXT.com