The problem when you don’t pixel align your graphics is that when they end up between pixels, they get all blurry like this:

(On the right is a zoomed in version of the same image.) With pixel aligning, the same drawing becomes:

Everything is beautiful again! Luckily, pixel aligning is easy to do. The main steps are: convert all of the relevant coordinates to the pixel grid, round them, then convert them back. There’s one little things to keep in mind while doing this- when you stroke (outline) something instead of filling it, the geometry works a bit differently. Here’s what a pixel aligned rectangle fill should look like on a pixel grid:

Note that the coordinates of the rectangle (shown in red) line up with the pixel grid points (which are integer pixel values). On the other hand, a pixel aligned rectangle stroke looks like this:

Now, the rectangle’s coordinates end up in between the pixels! In fact, they should be at the centers of the pixels (integer and a half values). And in case you weren’t already confused, here’s a rectangle with a two pixel stroke:

Now the coordinates are back to integer values again. Luckily, this is pretty easy to generalize: odd stroke sizes should be rounded to integer and a half pixel values and even stroke sizes (including a fill, which is a zero size stroke) should be rounded to integer pixel values. What about decimal stroke values that are neither even or odd? Well there’s not much you can do to pixel align in that case since the stroke itself being a non-integer pixel size is already un-pixel-align-able.

Here’s some code to help you make all your drawing nice and pixel aligned:

View LTPixelAlign code

LTPixelAlign is an NSView category that adds methods to pixel align NSRect’s, NSPoint’s, and stroke widths. The idea is that you can call these from your NSView’s drawWithRect: method to properly align the coordinates you use for drawing. Naturally these calls are resolution independence friendly- they rely on the view converting coordinates to pixels (with convertRectToBase: and friends) which takes the current resolution into account. At 1x, 1.25x, and 1.5x UI Resolutions, the non-aligned and pixel-aligned drawing shown above looks like:

If you’re using any additional geometry transforms (like NSAffineTransform) while drawing, you’ll have to take those into account when pixel aligning. For scaling and translating, you should transform the coordinates, then pixel align them, then un-transform the results. For rotations and shears, you’re usually better off just not pixel aligning, since there’s no way to make your transformed graphics line up with the pixel grid.

Of course if this sounds too complicated, you can always just use Opacity’s source code exporting, which does all this for you…

After some thought, the solution I came up with was just drawing the contents that you wanted to appear in slices the height of the rows in the proper column. If the cells are totally opaque (as they are in iTunes), then the cell’s normal contents (including row selection) won’t show through. I put together a basic example of this:

Download ArtworkColumn code

ArtworkColumn is a simple proof of concept to show how such a thing could be done. Things would get complicated if your content was more than just an image on a background, but in that case you could probably cache the content as an image and draw that cached images in slices in a similar way.

Update: Paul Kim has a much improved generalized version of this approach on his blog.

What are They?

Compositing operations determine how a graphic is drawn on top of existing graphics. They essentially determine what equation is used to determine the resulting color of the draw operation. These operations are often called Porter-Duff compositing after the programmers who defined them. In Cocoa, they’re represented by the NSCompositingOperation enumeration and their counterpart in Quartz is CGBlendMode. CGBlendMode was originally just for PDF blend modes, but in 10.5, the compositing operations were added. Note, though, that these new blend modes are not guaranteed to work with PDF CGContextRef’s, only bitmap ones.

Where They’re Used

NSCompositingOperation is used in several places in AppKit. Most prominently, you can set the compositingOperation for an NSGraphicsContext to determine the operation for subsequent drawing. NSImage also uses NSCompositingOperation in most of its drawing methods. Finally, NSCompositingOperation is used in several graphics related AppKit functions like NSRectFillUsingOperation, and in fact this is related to a common Cocoa graphics problem. NSRectFill and NSFrameRect both use the NSCompositeCopy operation, which is not the right operation to use when drawing with a partially transparent color. In that case, when the color gets drawn it will me partially black instead of partially transparent. To make sure your rects get drawn right with partial transparency, use NSRectFillUsingOperation and NSFrameRectWithWidthUsingOperation and specify NSCompositeSourceOver (which is generally what you use for “normal” drawing) for the compositing operation.

Highlighting

One convenient use for composite operations is to replicate the type of effect used by the Finder when you select an icon. This is essentially just darkening the icon, but not the background behind the icon. The operation to do this is NSCompositeSourceAtop, and here’s some example NSView drawing code:

- (void)drawRect:(NSRect)rect
{
   NSRect bounds = [self bounds];

   // Draw the image
   NSImage *image = [NSImage imageNamed:@"Opacity"];
   [image drawInRect:bounds fromRect:NSZeroRect
           operation:NSCompositeSourceOver fraction:1.0];

   // Draw the highlight
   [[NSColor colorWithCalibratedWhite:0.0 alpha:0.5] setFill];
   NSRectFillUsingOperation(bounds, NSCompositeSourceAtop);
}

And here’s the resulting output:

That’s not right! The problem here is that the NSView’s drawing is getting drawn together with the existing content (the window background). We need to isolate our drawing from what’s already there. A good way to do this is with a transparency layer, available from Quartz:

- (void)drawRect:(NSRect)rect
{
   NSRect bounds = [self bounds];

   // Start a transparency layer
   CGContextRef context = [[NSGraphicsContext currentContext]
                           graphicsPort];
   CGContextBeginTransparencyLayerWithRect(context,
                                           NSRectToCGRect(bounds),
                                           NULL);

   // Draw the image
   NSImage *image = [NSImage imageNamed:@"Opacity"];
   [image drawInRect:bounds fromRect:NSZeroRect
           operation:NSCompositeSourceOver fraction:1.0];

   // Draw the highlight
   [[NSColor colorWithCalibratedWhite:0.0 alpha:0.5] setFill];
   NSRectFillUsingOperation(bounds, NSCompositeSourceAtop);

   // End the transparency layer
   CGContextEndTransparencyLayer(context);
}

And now the image highlights correctly:

Coloring Images

Another nice trick you can do with the NSCompositeSourceAtop operation is re-coloring an image or graphic. This is a similar idea to highlighting, but goes further and completely replaces all of the (non-transparent) colors in the image, treating it sort of like a mask. I’ve found this useful for things like drawing images in table rows that should highlight in white when selected. I’ve put together a special function to do this coloring for you (including setting up a transparency layer to prevent coloring the background):

View LTColoredDrawing code

Here’s an example of how to use LTColoredDrawing in an NSView:

- (void)drawRect:(NSRect)rect
{
   NSRect bounds = [self bounds];

   // Start coloring
   NSColor *color = [NSColor blueColor];
   [color beginDrawingColoredInRect:bounds];

   // Draw the image
   NSImage *image = [NSImage imageNamed:@"Opacity"];
   [image drawInRect:bounds fromRect:NSZeroRect
           operation:NSCompositeSourceOver fraction:1.0];

   // Finish coloring
   [color endDrawingColoredInRect:bounds];
}

And here’s what this looks like in action:

Find Out More

You can explore compositing modes more with Opacity. Create an image with 2 or more layers, then select the top layer. Select the Window > Show Layers Info menu item and look at the Blend popup. The top two sections are PDF blend modes, and the bottom section includes the compositing modes. See what kinds of effects you can come up with!

Opacity includes opacityutil, a command line utility that can convert images between the formats supported by Opacity. You can use this functionality in Xcode to create a Build Rule that will dynamically convert .opacity images in your project to TIFF files (or any other supported format) at compile time.

To do this, first open your application’s project in Xcode. Add any .opacity images you want to the project (and include them in the appropriate target). Then, double click the application’s target to edit it. Select the Rules tab and click the plus button to add a Build Rule. Change the “Process:” popup to “Source files with names matching:” and enter *.opacity in the field (to match all .opacity files). Then change the “using:” popup to “Custom script:” and enter the following script (which should be all on one line):

opacityutil -save -out
  ${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}.tiff ${INPUT_FILE_PATH}

Finally, add an output file (by clicking the plus button). Change this output file to:

$(DERIVED_FILES_DIR)/$(INPUT_FILE_BASE).tiff

The result should look something like this:

With this setup, all .opacity files included in the target will get converted into TIFF images that will be added to the application. You can change the format for the built images by changing the two .tiff extensions above to an extension for another supported format, like .png for PNG images.

Opacity’s Xcode support was inspired by this post by Peter Hosey.

Of course if you don’t use Xcode, you can also manually build your .opacity image to a different format with Factories in Opacity.

Design

While working on my first program (Lexicon), I needed many graphics. Creating all of these, from icons to toolbar images, was a pain. At the time, Photoshop and Illustrator were the main tools for graphic editing, but they’re essentially jack of all trade editors. These programs are good for everything from photo editing to print graphics but aren’t designed specifically for editing screen graphics. It seemed to me that an application focused on just making screen graphics could do a much better job for users when they’re not editing photos or print graphics.

This made my goal for Opacity clear: Create a graphics editor for the screen, optimized for making images for icons, applications and the web.

Workflow

The part of creating screen images that I thought was the most painful was the workflow, so I focused a lot of attention to how to improve it. Before Opacity, the steps to create an application icon (for example), were as follows:

• Create a vector graphic in a vector editor (like Illustrator)
• Import and rasterize the vector graphic with a pixel editor (like Photoshop)
• Export the image at the necessary resolutions
• Mess around with differences in things like premultiplied colors and color spaces
• Use Icon Composer to piece the images back together and save as a .icns file
• Put the .icns file into an application to see how it will actually look

This workflow is already no picnic, but as you’re editing an icon you have to repeat this every time you make changes! For application and web graphics, you have to go through similar but slightly different workflows (see here for details). So not only do you need to buy and learn all of these different applications, you also have to learn all of the different workflows.

In Opacity, these steps and workflows are all unified into one application. You can design your graphics with vectors and see them at any different resolutions you want. And, of course, Opacity natively supports all of the formats you would need for the screen (including SVG as of Opacity 1.1).

Opacity also uses Factories to improve your workflow. A factory exports your image to a specified format and path. This removes all of the repetitive “Save As” or “Export” steps you’d normally have to go through, in addition to saving the export settings you’ve specified.

The Future

Since I started Opacity, there’ve been several new graphics editors released, but they all seem to follow Photoshop’s Swiss Army knife approach. When I designed Opacity, I focused on what the user wanted to do, instead of on using specific technologies. I think this approach works out well for users, in Opacity and in other programs like Aperture and Lightroom. I hope to see more new applications for the Mac that are designed this way in the future.

As resolution independence approaches, there’ll be even more need for a dedicated screen graphics editor like Opacity. I also have many features I plan to add to make it even easier for designers to make and implement great looking images.

View LTConversions code

Geometry

One of the most common mis-matching issues developers run into is the different geometry types in Quartz and Cocoa. Quartz has CGRect, CGPoint and CGSize while Cocoa uses NSRect, NSPoint and NSSize. They have all of the same attributes but are still different.

Luckily this situation is much improved in Leopard with a whole host of conversion functions like NSRectFromCGRect(). Even better, in 64 bit Cocoa all of the NS* types are typedef‘ed as their CG* equivalents! This is a great improvement, and even if you’re not 64 bit only, you can define NS_BUILD_32_LIKE_64 to still use the 64 bit versions of the NS* structures.

Core Image, though, uses yet another representation of geometric values. The CIVector class is used for rectangles, points, sizes and even 3D points. LTConversions includes methods to convert Quartz and Cocoa geometric values to and from their CIVector equivalents.

Color Spaces

Color Spaces are used to specify how to interpret the values in a color. Quartz uses CGColorSpaceRef and Cocoa uses NSColorSpace. NSColorSpace is great for converting color spaces-it can convert to and from CMProfileRef (used by ColorSync) and from ICC profiles (.icc files created with ColorSync Utility). New in Leopard, it can also convert to and from CGColorSpaceRef. Core Image does not have its own color space object, so in Leopard NSColorSpace can convert between pretty much any color space format you might need.

Colors

For colors, there three very similar flavors. NSColor, CGColorRef and CIColor are pretty much the same idea, and with LTConversions you can easily convert between them. Note that it doesn’t handle pattern color conversion since they’re treated a little differently in Quartz and AppKit (and don’t really exist in Core Image).

Paths

The situation with paths is a little strange. Quartz’s CGPathRef actually has (a little) more functionality than AppKit’s NSBezierPath. CGPathRef has cubic and quadratic Bézier curves, while NSBezierPath only has cubic curves. It’s not a major omission, but it seems strange that NSBezierPath is missing this, making it not quite a perfect mirror of CGPathRef. LTConversions has a method to convert a NSBezierPath to a CGPathRef, but not the other way.

Images

There’s also a host of image types. CGImageRef and CIImage don’t share NSImage’s concept of representations (which use the NSImageRep class), but otherwise they are very similar. LTConversions has methods for converting between these image types, but if you’re doing anything fancy with multiple image representations, you should probably do the conversion yourself.

Wrap Up

Leopard is required because of some of the new Color and Image conversions, and everything should work with (or without) Garbage Collection and in 64 bit. Leopard’s Core Animation doesn’t add any of its own new basic types, and generally uses those from Quartz (so using Core Animation together with Cocoa requires a lot of conversions). Of course, on a (purely hypothetical) platform that had Quartz but no AppKit or Core Image, most of these conversions would be unnecessary…

Some of the features that were missing in Tiger were type to select, source list appearance, and tooltips to show the text of a cell when it’s clipped. I implemented these and other behaviors for Lexicon, only to have them built in to NSTableView in Leopard! (not that I’m bitter) Check the AppKit release notes for all of the details on what’s new in NSTableView.

For Opacity, I put together a subclass of NSTableView that adds a few more features-specifically for handling keyboard presses. LTKeyPressTableView adds enter or return to edit a row, delete to delete the current row, and hooks to intercept left and right key presses.

View LTKeyPressTableView code

LTKeyPressTableView uses the table view’s existing delegate, adding a few optional delegate methods. Implement deleteSelectionFromTableView: to do something when the user presses delete with a row (or rows) selected, and goLeftFromTableView: or goRightFromTableView: for when they press the corresponding arrow keys. Enter automatically starts editing the first editable column of the table (if there is one) unless you implement preventEnterEditingTableView: to return YES. (Note: LTKeyPressTableView requires Leopard.)

By using LTKeyPressTableView for your tables, you can easily add user-friendly behavior with just a few delegate methods. As an added bonus, a key-press version of NSOutlineView is also included. Try them out!

This might sound a little backwards at first, but let me explain. In the most common updating circumstances, you want all of your customers on the latest version. Here’s an example: You first release your 1.0, and later release 1.1 to with a killer new feature-everyone updating should see the 1.1 release notes, which mention the new feature. Then later you release 1.2, which has some bug fixes. Now you’ll want everyone to update to 1.2, so you don’t want to show just the 1.1 changes by themselves. But, what about the people who are still running 1.0? You want them to see the changes and features in 1.1 in addition to those from 1.2. If we know what version they’re updating from, we can figure out which release notes to show (always going up to the latest release).

So I made a minor change to Sparkle to address this. In the checkForUpdatesAndNotify: method in SUUpdater.m, I added the line in bold:

// ... code to get appcastString from user defaults or Info.plist
SUAppcast *appcast = [[SUAppcast alloc] init];
[appcast setDelegate:self];
appcastString = [NSString stringWithFormat:appcastString,
    SUHostAppVersion()];
[appcast fetchAppcastFromURL:[NSURL URLWithString:appcastString]];

Now instead of getting a request for something like:

http://downloads.likethought.com/appcasts/lexicon.rss

I get a request for:

http://downloads.likethought.com/appcasts/lexicon.php?version=1.0

In this appcast file, you can specify a URL for the change notes. I send them all to the same PHP file (since they will all be updating to whatever the latest version is), and I pass this PHP file the $version variable. This is what my changes PHP file looks like:

<html>
    <body>
    <?php
        $versionNum = ereg_replace("[^[:digit:]]","",$version);
        while(strlen($versionNum) < 3) {
            $versionNum = $versionNum . "0";
        }
        if ($versionNum < 110) {
            echo "<h2>Changes in 1.1</h2><ul>";
            echo "<li>Added killer new feature</li>";
            echo "</ul>";
        }
        if ($versionNum < 120) {
            echo "<h2>Changes in 1.2</h2><ul>";
            echo "<li>Bug Fixes</li>";
            echo "</ul>";
        }
    ?>
    </body>
</html>

I only do very basic processing, strip out non-numeric text and convert the version to an integer, then check which changes they need to see. If you want to implement something similar, you could check for more differences in the version (like 1.0, 1.0b, 1.0rc-final, etc) or you could only prompt users to update to the same major version that they are running (i.e. not from 1.x to 2.x). The most important change is just the line in bold added to the Sparkle code. With that added, you can tweak to your heart’s desire.