On the nature of Pictures

By Chris Derossi, Chief Wizard, MacTutor Contributing Editor

A Quick Note on Pictures

This article has two puposes. The first is to more fully explain the information contained in Macintosh Technical Note #21; that is, the QuickDraw internal encoded picture format. The second bit of information concerns two problems which I have found relating to QuickDraw pictures.

To begin, let's go over the process of creating a picture. When you call OpenPicture, QuickDraw allocates a new handle, stores some initial data there, sets the picSave field for the current port, calls HidePen, and returns the new handle. The initial data consists of the length, rectangle, version, and clipping region of the picture.

When you then proceed to draw, calling QuickDraw with various artistic requests, QuickDraw notes that there is an open picture because of the valid picSave handle. Because of this, QuickDraw translates your request into its own picture shorthand, and appends this information to the picture data. The length information at the beginning of the picture data is increased to reflect the new data. Since HidePen had been called, none of this shows up on the screen. (Unless, of course, you have called ShowPen without a balancing call to HidePen.)

Finally, you call ClosePicture which calls ShowPen, places an end-of-picture marker in the picture data, and sets the picSave field to NIL.

Now, let's go through some picture data byte by byte. The first two bytes of information are the length, which represent the length of ALL of the data, including the length bytes themselves. Next are eight bytes (4 words/Integers) of rectangle information (top, left, bottom, right). This is the rectangle which was passed as the parameter to OpenPicture. Following this are the picture opcodes and their data.

A picture opcode is a single byte which tells QuickDraw to do something, or how to interpret some amount of additional data. The length and composition of the data following the opcode depends on the opcode itself. The first opcode in a picture is always $11 which represents "Version". This opcode has one byte of data which represents the version number. Whenever QuickDraw encounters $11, it knows to treat the next byte as the version number, and to skip over it to get to the next opcode. Opcodes and their data are packed together. That is, immediately following an opcode and its data is the next opcode.

After the version, there may be any number of QuickDraw opcodes. The last opcode in a picture is always $FF which stands for "End-of-Picture". Data after this opcode is ignored. (Under normal circumstances, there won't be any further data.)

If the picture was created in the usual manner (i.e. with OpenPicture instead of generating the picture data some other way) then the next opcode is $01 which is "ClipRgn". The data following this opcode is a region, the first word of which is the length of the region. Normally, it will look something like the data in Figure 1. When you call OpenPicture, the region is copied from the current port's clipping region.

Most of the opcodes are pretty straightforward. Some, however, could use a little explanation. Most of the verb-object calls have a corresponding verbSameobject call. The latter simply uses the last explicit data (be it a Rect, RRect, etc) from a prior call for its own argument. For example, if you wanted to do a paintRect (opcode $31) on a rectangle with coordinates (0, 0, 45, 45) and then invertRect the same rectangle, the resultant picture data would look like that in Figure 2.

Instead of passing the fill pattern as an argument each time as in the QuickDraw call, pictures use the concept of a 'current' fill pattern which the TechNote calls "thePat". (This is analagous to the current pen pattern.) To fill several Rects with the same pattern, there would be one opcode to set thePat ($0A), and then several fillRect opcodes and their respective rectangles. (Figure 3).

Because simple lines and text are so common, there are several versions of each so that QuickDraw can use the version that takes the least amount of space. Lines come in two sizes: regular and short. Short lines have vertical and horizontal lengths which can be represented by a single byte (-128 to 127). The horizontal and vertical lengths are then used instead of the line endpoint. Both line and short line (opcodes $20 and $22) also include the starting endpoint. The remaining two line opcodes ($21 and $23) start the line from the current pen location, which could have been set by previous line or text drawing.

If text is to be drawn only a short distance from the current pen location, QuickDraw uses opcodes $29, $2A, or $2B to move the pen horizontally, vertically, or both before drawing the text. If the starting location for the text is too distant to represent with single byte offsets, opcode $28 is used, and the actual point at which to draw the text is specified.

The last 'gotcha', and the first problem I'd like to discuss both concern the SetOrigin call, which is opcode $0C. This opcode takes four bytes (two words/Integers) as arguments. BUT, the two words do not represent the actual origin that you specified with the SetOrigin call; Instead, they are the offset from the current origin to the new one.

For example, if you were at origin (0,0) and you made a SetOrigin(15,10) call, the picture data would be $0C $00 $0F $00 $0A. More importantly, if you were in a situation where the origin was unknown, you might be inclined to call SetOrigin(0, 0) before performing any drawing. This can have some unexpected side effects. Consider the following scenario:

Your code does not know where the origin is, so it calls SetOrigin(0, 0). Let us say that the origin was in fact at (15, 10). QuickDraw would record an origin change of -15, -10 ($0C $FF $F1 $FF $F6). Then you do your drawing and close the picture.

Now, since you didn't make any more SetOrigin calls, you know that the origin is at (0, 0), which is where you want it to be. So you call DrawPicture. QuickDraw would then come across the $0C opcode and changes the origin to (-15, -10), and your drawing would be in the wrong place! The way to avoid this problem is to call SetOrigin before you open the picture, and again before you draw the picture.

The technique of changing picture origins has a use, for example, in printing, when you want to draw a very large picture. You can simply originate different areas of the picture over the 'printer paper' port and draw the picture. In this way, you can print your large picture on several pieces of paper. Moving pictures around is also a nice way to show different parts of a picture in response to a scroll bar; You only have to generate the display once, and just draw the picture with offsets based on the scroll bar values.

But a common occurrance while doing this is to have the picture vanish when it is drawn at any location other than the one where it was created. The reason for this is simple but elusive.

Recall that when you call OpenPicture, QuickDraw copies the clipping region of the port into the picture data. Well, a newly created port has a very large clipping region, specifically, a rectangle with coordinates (-32767, -32767, 32767, 32767). In hexadecimal, those coordinates translate to ($8001, $8001, $7FFF, $7FFF).

If you offset the picture rectangle just one pixel to the right, QuickDraw re-calculates all of the coordinates in the picture data, including those of the clipping region. But, if you add 1 to $8001, you get $8002 (which is -32766) and 1 + $7FFF is $8000 (decimal -32768). This leaves you with coordinates of (-32767, -32766, 32767, -32768) for the clipping rectangle. This is an empty rectangle because the right side is less than the left side. The whole picture gets clipped!

The solution to this problem is as easy as the solution to the last one: Set your clipping region before you open your picture. You can keep the clipping region very large, but stay away from the values that come close to hex $8000. Such is life with finite mathematics.

I hope this has helped to shed some light on your use of pictures. Used intelligently, they can save you from redrawing the same things again and again. As a side note, if you are interested in pictures and the LaserWriter, you should see TechNote #27: The MacDraw Picture Format.

Ciao.

________________________________________________________________________________

Macintosh Technical Notes

#21: Quickdraw's Internal Picture Definition

See also: QuickDraw

Programming in Assembly Language

Written by: Ginger Jernigan April 24, 1985

__________________________________________________________________________________

This technote describes the internal format of the QuickDraw picture data structure.

__________________________________________________________________________________

This technote describes the long awaited internal definition of the QuickDraw picture. The information given here is meant for DEBUGGING PURPOSES ONLY. It is NOT useful in writing your own picture bottleneck procedures. The reason is that if we add new objects to the picture definition, your program will not be able to operate on pictures created using standard QuickDraw. Your program will not know the size of the new objects and will, therefore, not be able to proceed past the new objects. (What this ultimately means is that pictures will not be downward compatible; you can't process a new picture with a old bottleneck proc.)

Before listing the opcodes a little information is in order. An "opcode" is a number that DrawPicture, for example, uses to determine how to draw that particular object in the picture, and how much data is associated with it. The following list gives the opcode, the name of the object, the associated data, and the total size, in bytes, of the opcode and associated data. To better interpret the sizes, please refer to page 4 in Programming in Assembly Language. For types not described there, here is a quick list:

opcode 1 byte

point long

0..255 1 byte

-128..127 1 byte

rect 8 bytes

poly 11+ bytes

region 10+ bytes

fixed point number long

pattern 8 bytes

Each picture definition begins with a picsize (word), then a picframe (rect), and then the picture definition, which consists of a combination of the following opcodes:

Opcode Name Additional Data Total Size (bytes)

00 NOP none 1

01 clipRgn rgn 1+rgn

02 bkPat pattern 9

03 txFont font (word) 3

04 txFace face (byte) 2

05 txMode mode (word) 3

06 spExtra extra (fixed point) 5

07 pnSize pnSize (point) 5

08 pnMode mode (word) 3

09 pnPat pattern 9

0A thePat pattern 9

0B ovSize point 5

0C origin dh, dv (word) 5

0D txSize size (word) 3

0E fgColor color (long) 5

0F bkColor color (long) 5

10 txRatio numer (point), denom (point) 9

11 picVersion version (byte) 2

20 line pnLoc ( point ), newPt ( point ) 9

21 line from newPt ( point ) 5

22 short line pnLoc ( point ), dh, dv (-128..127) 7

23 short line from dh, dv (-128..127) 3

28 long text txLoc ( point ), count (0..255), text 6+text

29 DH text dh (0..255), count (0..255), text 3+text

2A DV text dv (0..255), count (0..255), text 3+text

2B DHDV text dh, dv (0..255), count (0..255), text 4+text

30 frameRect rect 9

31 paintRect rect 9

32 eraseRect rect 9

33 invertRect rect 9

34 fillRect rect 9

38 frameSameRect rect 1

39 paintSameRect rect 1

3A eraseSameRect rect 1

3B invertSameRect rect 1

3C fillSameRect rect 1

40 frameRRect rect 9

41 paintRRect rect 9

42 eraseRRect rect 9

43 invertRRect rect 9

44 fillRRect rect 9

48 frameSameRRect rect 1

49 paintSameRRect rect 1

4A eraseSameRRect rect 1

4B invertSameRRect rect 1

4C fillSameRRect rect 1

50 frameOval rect 9

51 paintOval rect 9

52 eraseOval rect 9

53 invertOval rect 9

54 fillOval rect 9

58 frameSameOval rect 1

59 paintSameOval rect 1

5A eraseSameOval rect 1

5B invertSameOval rect 1

5C fillSameOval rect 1

60 frameArc rect 9

61 paintArc rect 9

62 eraseArc rect 9

63 invertArc rect 9

64 fillArc rect 9

68 frameSameArc rect 1

69 paintSameArc rect 1

6A eraseSameArc rect 1

6B invertSameArc rect 1

6C fillSameArc rect 1

70 framePoly poly 1+poly

71 paintPoly poly 1+poly

72 erasePoly poly 1+poly

73 invertPoly poly 1+poly

74 fillPoly poly 1+poly

78 frameSamePoly (not yet implemented) 1

79 paintSamePoly (not yet implemented) 1

7A eraseSamePoly (not yet implemented) 1

7B invertSamePoly (not yet implemented) 1

7C fillSamePoly (not yet implemented) 1

80 frameRgn rgn 1+rgn

81 paintRgn rgn 1+rgn

82 eraseRgn rgn 1+rgn

83 invertRgn rgn 1+rgn

84 fillRgn rgn 1+rgn

88 frameSameRgn (not yet implemented) 1

89 paintSameRgn (not yet implemented) 1

8A eraseSameRgn (not yet implemented) 1

8B invertSameRgn (not yet implemented) 1

8C fillSameRgn (not yet implemented) 1

90 BitsRect rowBytes, bounds, srcRect, dstRect, mode, 30+unpacked

byteCount, unpacked bitData bitData

91 BitsRgn rowBytes, bounds, srcRect, dstRect, mode, 30+rgn+

maskRgn, byteCount, unpacked bitData bitData

98 PackBitsRect rowBytes, bounds, srcRect, dstRect, mode, 30+packed

byteCount, packed bitData bitData

99 PackBitsRgn rowBytes, bounds, srcRect, dstRect, mode, 30+rgn+

maskRgn, byteCount, packed bitData packed bitData

A0 shortComment kind(word) 3

A1 longComment kind(word), size(word), data 5+data

FF EndOfPicture none 1