bhyde@inmet.UUCP (06/24/85)
What a sad note about quickdraw and the laser writer. This is no comfort but it turns out that regions aren't really very useful beyond the screen maintainance problem. A 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. 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. ben hyde.
stew@harvard.ARPA (Stew Rubenstein) (07/03/85)
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.
schley@mmm.UUCP (Steve Schley) (07/08/85)
Ben Hyde posed this problem: > ... 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? Sure do: use White-Out! Here's how I do it... Assuming that your application can always draw (or redraw) line a after line b, simply draw line b, then change pen color to background, change pen size to a few pixels wider than the lines being drawn, offset the endpoints of line a by half the new wider line width, and draw this new line a. Finally, reset the pen and line attributes and draw the real line b. Sure, this isn't as clean as the region technique which handles the hidden line problem on its own, but it works, and making regions around lines isn't always clean, either.-- Steve Schley ihnp4!mmm!schley