Now that the source transfer modes were added for drawing text, a logical next step was adding support for drawing the most basic bitmap-only PICT resources. For this purpose, we added a very simple test PICT resource into the Fake ROM resources, which we used to test this feature.

More than a bitmap

What makes the basic QuickDraw PICT format different from many other image formats is the fact, that it is actually not a pure bitmap container, but rather a recording of drawing commands, which can be played back at any time. Basically this allows majority of QuickDraw commands to be “recorded” into a picture, and later played back. Even better, these pictures can be “played” also on other devices besides screen, such as printers! This allows a picture with geometric shapes to have a rasterized on-screen representation, but appear as a sharp image on for example a laser printer. Furthermore, these pictures can be scaled during playback to a target rectangle, allowing them to adapt to different screen/device sizes as appropriate. Of course, all this makes displaying a simple scanned bitmap photo of a cat a bit more complex than one would expect.

A simple PICT image

Attempting to create the monochrome old-style PICT resource was a bit challenging on modern Macs, so we ended up transferring the photo on the reliable good old PowerBook G3, and exporting to resource from there using old version of PhotoShop.

Playback time!

So basically what we needed to display the cat picture, was just take the PICT resource and do the following:

1. Read the picture size and picFrame from the header
2. Save copy of content of current GrafPort
3. Set up defaults for the GrafPort (including new clipping region)
4. Initialize a playback state record
5. Execute each picture opCode from picture data one by one
6. Dispose playback state and restore original GrafPort state

Even in this simple format, the following opcodes were required for the test PICT: Version, LongComment, PackBitsRect, and EndOfPicture.

All other opcodes were trivial to implement, except PackBitsRect which ended up using UnpackBits trap, so we had good excuse for implementing it also at this point. With unpacking implemented, the drawing ended up with a simple call to StdBits, which was was already previously added for text drawing, and we got the cat quickly on the screen:

As clipping was already implemented, we were able to goof around by drawing the PICT in funky clipping region (with some text added for fun):

Region recording

Previously, during the spring, we had added the basic region operations, which already allow us to do a bunch of cool stuff, but next up on the list was implementing region recording. This neat feature QuickDraw allows the program to open a new output region for “recording”, to which certain QuickDraw “FrameXXX” operations will output inversion points into. This includes StdLine, StdOval, StdRect, StdRgn, and RoundRects.

The article on MacGUI, which was mentioned earlier when discussing regions, also contained a neat screenshot of results of OpenRgn/CloseRgn operation with accompanying Pascal source code. We made adaption of this code for the C Toolbox testbed, so we could have a picture to compare to, to see that the results would match ones expected on a real Mac.

At the same time, we were working on adding “source” transfer mode support to the region-clipping blitter, as transferring text to screen uses those to handle moving the text from offscreen buffer to the screen (previously we only implemented the non-clipped blitter). After getting this to work, there was also a nice benefit that non-scaled CopyBits can also be implemented easily soon, although only for cases where source and destination bitmaps are different (ScrollRect and window manager will use same source and destination, forcing inverted blitting direction depending on their locations).

A few days earlier, we got the non-styled direct-to-screen text drawing working, but we also need to support all the other cases. At this point, we want to have the clipping and styling support, but we’ll leave the scaling to some point in the future.

As styled text required an offscreen buffer for styling, we started by adding that. Interesting feature of QuickDraw FMSwapFont mapping is, that as any styles can be combined together, the FOut record contains a set of styling attributes which tells the text rendering how to adjust the final appearance of the font, such as bolding amount, how much slanted the italic style is, how deep the shadow is, etc.

After a few days to debugging, bug-fixing, more debugging, and even more bug-fixing, we go the text to render properly:

An interesting discovery was, that it appears that “Classic”-type QuickDraw and Color QuickDraw handle the outline styles a bit differently. This may be due to the way outline/shadow styled text is combined during drawing, as the “inside” of outlined text is drawn over the shadow/outline using srcXor mode. Another interesting point is, that even Color QuickDraw falls back to the “old” type drawing if the GrafPort is old-type monochrome port (i.e. high-order bit of rowBytes is zero)

Font Manager and the notorious FMSwapFont

As mentioned earlier, the next target is to get QuickDraw text rendering to work. For this purpose, we’ve been working on important part required by it, The Font Manager. The most important interface between QuickDraw and Font Manager is the FMSwapFont trap, which takes the FMInput record, and outputs an FMOutput record. On a real Mac, the font substitution has a bunch of special cases which we luckily don’t need to worry about; for example, we don’t need to worry about choosing right font to display the disk-switch alert. However, there are a number of substitutions we need to support:

• Substitute non-present font to default font
• Choosing nearest-size font strike to substitute a non-present (scaled) size of a font
• FOND tables
• Fallback to old FONT resources in case requested FOND does not exist (using the familiar family * 128 + size formula)
• Etc.

Getting the strike loaded and on the screen

Majority of time spent for this milestone so far was investigating and implementing the quirks of the previously mentioned FMSwapFont trap. After finding the correct (or near-correct) strike, we finally got a FONT resource which we could work on. Of course, this meant that as first step dump the raw font bitmap on the screen buffer byte-by-byte 🙂

Of course getting the actual text to output, each of those characters would have to be individually masked and blitted to the correct location. For the first test, the original QuickDraw luckily appears to have “optimized” way to blitting non-clipped, non-scaled, non-styled srcOr-mode text directly to the screen, without having to go through offscreen buffer for styling and clipping. Implementing this was also pretty straightforward, resulting in the following tidy output using different fonts:

The “Atkinson” circle algorithm

After the groundwork done for rectangle drawing, the rest of geometric shapes were pretty easy to add. To make sure the results of drawing operations would look exactly like on a real Mac, the Midpoint circle algorithm was implemented as closely to what Atkinson used as possible

https://en.wikipedia.org/wiki/Midpoint_circle_algorithm

More information about the Midpoint (“Atkinson”) circle algorithm

The fun thing is, that a bunch of QuickDraw primitives actually share this method, so not only did this allow drawing Circles, it also enabled drawing ovals (basically stretched circles, thus this is why overly long framed ovals on Mac tend to have holes on their silhouette), and the infamous round rectangles. Also drawing arcs benefits from this, but we won’t be needing them at least for some time so we won’t touch them at this point.

Here’s also a neat video of round rectangle clipping:

What are regions exactly?

Short answer: The most important part which made Mac user interface possible.

Long answer: The regions, in the form as they are used in the original Mac, were invented by Bill Atkinson as solution to solving the problem of creating effective algorithms for masking drawing commands with arbitrary bitmap shapes, and performing geometric logical operations with them. There is a good article on macGUI, which gives a better backstory and technical explanation about what regions are from the user’s (or programmer’s) point of view:

http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2010/8/29_Regions.html

Regions in the QuickDraw

One interesting feature of regions is, that when a region is rectangular, it will always have fixed size (10 bytes), and its bounding box can be used as in rectangular clipping. This helps reducing sometimes drawing in complex regions to trivial rectangular blitting operations, which are much faster than ones requiring region masking for each scanline:

However, the need for actual region operations comes up very quickly, when wanting to do anything that ends up being non-rectangular. For example, the test case we used at this point, was just to get union of two rectangles into region, and fill that with a solid pattern.

Region decompression and re-compression

In memory, regions are stored in sort of compressed format, with each scanline containing horizontal indices of the inversion points on that scanline. However, during operations, they need to be manipulated as points, with horizontal and vertical coordinate. To achieve this, the region is decompressed during the actual operations into a point buffer, where points from both source regions are added as needed by the actual operation. The resulting points from these operations are then sorted, and re-compressed into a new region. At this point, we do the sorting with slow bubble sort, which will be replaced by a more efficient Quicksort later.

Funny thing about InsetRgn is, that it takes a bit more complex way of performing the operation: For insetting, the region is actually getting inset twice, once for both axis, but the horizontal and vertical coordinates are flipped for the second inset, so the horizontal inset is actually ran *twice*.

Drawing the regions

After the complexity of geometric operations on regions, doing the actual drawing with them is pretty straightforward. The region image blitter is pretty similar to the rectangular blitter, but it takes up to three regions as arguments, which get expanded into horizontal scanline buffers during the drawing. Each of these buffers is updated on each vertical coordinate, and together they form a bitmask, which can be simply ANDed together and used to mask the transfer of source bits to the destination.

After a few missteps, we finally got the region clipping to work nicely: