jmunkki@santra.UUCP (Juri Munkki) (01/11/88)
Regions: The Real Story, a Technical Note Copyright 1988 Juri Munkki
(Well, sort of) All rights reserved
1. What We Thought We Knew
The May 1987 "ABC's of C" and October 1987 "C Workshop" in MacTutor
provide descriptions of the region data structure. Obviously the region
structure is reserved by apple and subject to change without notice
(it's undocumented), but sometimes it's just too slow to do things the
way apple intended us to do them. For this reason (and debugging
purposes) it is useful to be aware of the structure.
Unfortunately the "ABC's of C" article is not complete and the "C
Workshop" gives slightly false information.
2. Conventions
In this article the structure I call the region is in fact the data
that comes after the length word and size rectangle. The first 10 bytes
are documented and are thus of no interest to us.
While I'm on the subject of documentation, I might mention that the
note in IM I-183 about the speed of OffSetRgn is misleading. None of
the information in a region is stored in offset format and OffSetRgn
is a relatively slow operation when the region is very complex.
3. What We Now Know
A region can be thought of as a collection of block descriptions, but
each block is related to those above it. The block description starts
with the smallest line coordinate included in the block and ends with a
$7FFF. The words in between the start and end describe the difference
between the current block and the one above it.
Let's examine a union of two rectangles: 10,10-100,100 and 80,80-200,200
The first line would then contain 10, 10, 100, $7FFF.
This means that the first block starts at y position 10 and the pixels
between x 10 and 100 are included in the block. The block extends
until the block below it starts. The following block describes the
changes to be made in the previous block. The second block would then
be: 80, 100, 200, $7FFF. This means that those pixels that were
between 100 and 200 should be inverted starting from y position 80.
The next block would then tell to remove pixels between x positions
10 and 80 starting from y position 100. It should look like this: 100,
10, 80, $7FFF. The last block of our region would then cancel the
remaining pixels from the block: 200, 80, 200, $7FFF. Since it is the
last block, an extra $7FFF is appended.
The complete region structure would look like this:
Y Pixels set
10 10 100 $7FFF 10-100
80 100 200 $7FFF 10-200
100 10 80 $7FFF 80-200
200 80 200 $7FFF None
$7FFF
+----+
Block 1 | | 10-100
| ..+----+
Block 2 | : : | 10-200
+--+.: |
Block 3 | | 80-200
+------+
Block 4
Figure 1
In hexadecimal:
000A, 000A, 0064, 7FFF, 0050, 0064, 00C8, 7FFF,
0064, 000A, 0050, 7FFF, 00C8, 0050, 00C8, 7FFF, 7FFF
I hope this helps somebody. I thought about sending it to MacTutor, but then
decided against it. MacTutor is welcome to publish it if they want...
I reserve the rights to myself, so please do not reproduce in part
or whole without my permission.
Juri Munkki
jmunkki@santra.hut.fi
jmunkki@fingate.bitnetsc258202@gwusun.gwu.edu (fortin robert e) (04/12/89)
Is there anybody out there who has written a program in C that can generate a region given a bitmap which works in an edge-traversal fashion. ...The Mann\x
jackiw@cs.swarthmore.edu (Nick Jackiw) (04/12/89)
In article <1324@gwusun.gwu.edu> sc258202@gwusun.gwu.edu (fortin robert e) writes: > Is there anybody out there who has written > a program in C that can generate a region > given a bitmap which works in an edge-traversal > fashion. I think Apple licenses a trap subroutine of the form FUNCTION BitMapRgn(region:RgnHandle; theBits:BitMap): OSErr; which might do what you want. Actually, I think it generates a region such that ALL zero points in the bitmap are excluded from the region. This means if your bitmap has holes in it, they'll be cropped out of the region. (This may or may not be what you want.) At any rate, don't be afraid to write to them. Their prices are quite reasonable, especially (I think) for non-commercial development. They're at: Software Licensing / Apple Computer 20525 Mariani Ave MS 28-B Cupertino, CA 95014 AppleLink: SW.License ----------- Alternately, if you want only the outer-periphery of your bitmap and no interior holes, the algorithm should be rather trivial to write as a general "raster-scan polygon" sort of deal. E-mail me for further details. Hope this helps. > ...The Mann\x -- _ _|\____ Nick Jackiw | Visual Geometry Project | Math Department / /_/ O> \ ------------+-------------------------+ Swarthmore College | O> | 215-328-8225| jackiw@cs.swarthmore.edu| Swarthmore PA 19081 \_Guernica_/ ------------+-------------------------+ USA