<< shiftedbits

As programmers on OS X are well aware, the units of mach_absolute_time() have been nanoseconds since 10.2, although this was only documented since 10.5. As the iPhone runs a slimmed down version of OS X, I thought it reasonable that the units would remain the same on the device.

[Update] As Justin points out below, this was never the case. A complete misread of the documentation on my part. I managed to work on only machines for which the units of mach_absolute_time() were nanoseconds.

So if you’re trying to get some timing from the iPhone using mach_absolute_time() and seeing times that indicate faster results on the iPhone, (not that this happened to me…), make sure to account for the difference in timebase.

Here’s the code for conversion between the mach_absolute_time() units and nanoseconds:

#include <mach/mach_time.h>

/* Get the timebase info */
mach_timebase_info_data_t info;
mach_timebase_info(&info);

uint64_t start = mach_absolute_time();

/* Do some code */

uint64_t duration = mach_absolute_time() - start;

/* Convert to nanoseconds */
duration *= info.numer;
duration /= info.denom;

/* Log the time */
NSLog(@"My amazing code took %lld nanoseconds!", duration);

Quick bug fix update:

1.2.2 Fixes a crash due to a missing implementation of __KVOAdditions__dealloc__original__ on NSObject.

1.2.1 now runs on the iPhone.

The new updates are in SVN at http://svn.shiftedbits.org/public/KVOAdditions/trunk and tagged at http://svn.shiftedbits.org/public/KVOAdditions/tags/1.2.2

Key value observing is quite a useful tool, no doubt about it. But it has a singularly annoying manner of informing the observer of a change. The -[NSObject observeValueForKeyPath:ofObject:change:context:] method is sent to the observer when a change occurs. It’s up to the implementor to parse the `change’ dictionary to figure out what changed.

When I use observers, I usually want a method called on my class when a change occurs, similar to target/action with UI elements. So my -[NSObject observeValueForKeyPath:ofObject:change:context:] is basically a set of if’s for each key I’m observing that calls the appropriate method.

This turns out to be pretty nasty, especially when you have multiple classes in a hierarchy implementing the method. It wasn’t obvious to me that I needed to call super in this method. Thirty minutes of debugging later, and I was convinced there had to be a better way of doing it.

To this effort, I present two new APIs. To NSObject, I add -[NSObject addObserver:forKeyPath:options:selector:] and to NSArray, -[NSArray addObserver:toObjectsAtIndexes:forKeyPath:options:selector]. The code is available here, or keep reading for the details.

Update 1.1: Two critical bug fixes. Please update to the new version if you have the old one. Also, anonymous svn is now available if you want to use an external. http://svn.shiftedbits.org/public/KVOAdditions/trunk. Continue reading →

As part of a graphics API I’ve been working on (for my own use, it’s hardly ready for production,) I decided to try learning SSE optimization by making the compositing routine faster.

I came up with an implementation which, according to my tests, is 3-5X faster than the non-optimized version. The optimized version below composites a single color starting at a destination pixel buffer for a specified run of pixels. It uses source over compositing on a RGBA, 8bpc, integer pixel buffer.

The optimized version is presented below:

Continue reading →

As the documentation mentions, a transparency layer allows subsequent drawing to be rendered in a separate, fully transparent buffer before being composited to the destination context. In the absence of a clipping region, this buffer is the same size as the destination context, requiring a context-sized buffer regardless of the actual drawing bounds. Creating a transparency layer for a small section of content, then drawing this layer in a window, for example, results in a window-sized buffer for the layer. When the layer is composited into the destination, the entire buffer must be composited — CoreGraphics doesn’t keep track of where the actual drawing is.

This, of course, is slow, especially for several transparency layers.

To help speed things up, clip the context to the bounds of any drawing in a transparency layer before beginning the transparency layer, such as below:

CGRect artRect = CGRectMake(50,50,100,50);
CGContextClipToRect(context, artRect);

CGContextBeginTransparencyLayer(context, NULL);

/* Draw layer content here */

CGContextEndTransparencyLayer(context);

I’ve created a demonstration program to illustrate the effects of clipped vs. unclipped transparency layers. To see the effects, open Quartz Debug (/Developer/Applications/Graphics Tools/Quartz Debug.app) and turn on “Flash screen updates.” Then, open the Transparency Layer program. There are two windows, the left showing the drawing without clipping and the right clipping to the approximate art bounds. The views are redrawing four times per second. Notice that the unclipped view redraws its entire content while the clipped view redraws only the actual art.

Finally, using -[NSView setNeedsDisplayInRect:] clips the drawing to the specified rect.