Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site harvard.ARPA
Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!edsel!bentley!hoxna!houxm!mtuxo!mtunh!mtung!mtunf!ariel!vax135!timeinc!phri!pesnta!amd!amdcad!decwrl!decvax!genrad!mit-eddie!think!harvard!stew
From: stew@harvard.ARPA (Stew Rubenstein)
Newsgroups: net.micro.mac
Subject: Re: Deficiencies in QuickDraw support fo
Message-ID: <218@harvard.ARPA>
Date: Wed, 3-Jul-85 01:59:49 EDT
Article-I.D.: harvard.218
Posted: Wed Jul  3 01:59:49 1985
Date-Received: Tue, 2-Jul-85 06:34:20 EDT
References: <202@harvard.UUCP> <26700020@inmet.UUCP>
Organization: Aiken Computation Laboratory, Harvard
Lines: 63

Ben Hyde @ inmet writes:

>   This is no comfort but it turns out that regions aren't
> really very useful beyond the screen maintainance problem.

Fact is, I looked at what I had to do, and the implementation that I
chose used regions.  They appeared (and still appear) to be the best
solution for my application.  If by "screen maintenance problem" you
mean the stuff that the window manager does with visRgns and updateRgns,
then I think you are selling regions short.  If you have a broader
meaning in mind, then that's like saying, "Air's really not useful
beyond the breathing problem."

> region is encoded in bands.   Each band is a contigous set of rows all
> identical.  Thus a rectangle can be encoded in a single band,
> but a diamond or circle will require a band for each row of pixels.
> Regions are as grainy as the Mac screen.
> 
> You can slip around the problem by drawing to a virtual screen with the
> resolution of the your device but then the application must support device
> dependent modes.

Sure, but there's a device independant way to support it -- via the rPage
rectangle and iVRes/iHRes fields in the prInfo field of the print record.
It's not hard to scale coordinates depending on the output device resolution.

By the way, why are the iVRes and iHRes fields still 72 on the
imagewriter and on the laserwriter???  What good are these if every
printer driver is going to use the same 72 dpi resolution and scale
internally?  I know that one wants a consistent interface for those who
wish to ignore the device resolution, but one also wants the capability
to access the full resolution of the device!  The fact is, graphical
output on the laserWriter is UGLY AS SIN due to line endpoints being
limited to 72 dpi resolution, not to mention the ugly variable-width
quickdraw pen simulation, unless you generate postscript yourself!
Perhaps the future versions of the printer drivers should have a
PrFullRes(thePrintRec) call which will adjust the prInfo field to
describe the full resolution of the device, and set a flag turning off
scaling of the coordinates.  How about it, Apple?

>   So there are good reasons to use polygons and not regions.
> No comfort if you've designed the entire system to use regions for
> the hidden line elimination problem.

Yeah.  Consider this part of my application.  You have two line segments
which are known to cross, one "behind" the other.  I want to "cut out" a
little bit of the one which is "behind", so it looks like this:

	\      / <- line b
	 \    /
	  \  /
	   \ 
	    \
	  /  \
	 /    \
	/      \ <- line a

Now, the way that occurred to me was to subtract a region of fixed
width around line a from the clipping region while drawing line b.
Now what I will have to do is compute the points where line b crosses
the boundaries of that region myself.  Anyone got a better way?

> 			ben hyde.