CFTree Is Leaking It’s Children

It’s 12:40 AM, and I’ve got a client related deadline tomorrow afternoon – so what am I doing writing a blog post? The real answer is: I’m not really sure; but the more relevant answer is: Because this took far too long to track down, and I’d like to save someone else the time I wasted. Essentially it boils down to the fact that the documentation for CFTree is not only misleading, but it seems to be flat out wrong.

First, you may be sitting there wondering what the hell a CFTree is, and several weeks ago I would have wondered the same thing. CFTree is (as it’s name suggests) a tree structure; it is a pseudo-collection *, and is used to organize elements in hierarchical relationships. In this case, the lines between the contents of the collection and the collection itself are blurred. A tree can having relationships with other trees (potentially parents and children), and can hold a payload the size of a pointer, which allows you to store integers, pointers to structs, or objects – even other collections if you feel being all wild and crazy.

This post isn’t supposed to be about all the fancy things you can do with a CFTree, but rather, this line in the documentation for CFTree:

Releasing a tree releases its child trees, and all of their child trees (recursively). Note also that the final release of a tree (when its retain count decreases to zero) causes all of its child trees, and all of their child trees (recursively), to be destroyed, regardless of their retain counts.

The way I interpret that suggests I would have created and (completely) destroyed a tree if I were to do the following: Create Root Tree, Create Child Tree, Append Child Tree, Release Child Tree, Release Tree. Destroying the root tree does not release or destroy it’s children trees. It’s been difficult to track down for a variety of reasons, but I suspected something was wrong (even if I only found one google result on the topic), and I set out to prove it. Lets look at some code.

There’s some very non-cocoa looking stuff going on here, but the details are something I’d like to dive into in a later post. The important thing is that we’ve created a tree with a release callback pointing to DummyReleaseCallback. This is the function that the CFTree is going to call when it is done with the value passed in to treeContext.info, which is that payload I was talking about before. It’s safe to think of this whole process in the same manner you would an NSArray sending the release message to an object when it it removed from the collection.

static void DummyReleaseCallback(const void *info )
{
	NSLog(@"release %i", (int)info);
}

...

{
	CFTreeContext treeContext;
	treeContext.version = 0;
	treeContext.retain = NULL;
	treeContext.release = DummyReleaseCallback;
	treeContext.copyDescription = NULL;
	treeContext.info = (void *)1;
	
	// DummyReleaseCallback should be called after we release this tree
	CFTreeRef dummyTree = CFTreeCreate(NULL, &treeContext);
	CFRelease(dummyTree);

	...

2011-09-07 01:13:26.836 CFTree[1044:f203] release 1

Perfect, the release callback is being called when the tree is released. Let’s add some children…


	...

	treeContext.info = (void *)2;
	CFTreeRef root = CFTreeCreate(NULL, &treeContext);

	for (NSUInteger i = 0; i < 10; i++) {
		CFTreeContext treeContext;
		treeContext.version = 0;
		treeContext.retain = NULL;
		treeContext.release = DummyReleaseCallback;
		treeContext.copyDescription = NULL;
		treeContext.info = (void *)100 + i;
		
		CFTreeRef newChild = CFTreeCreate(NULL, &treeContext);
		CFTreeAppendChild(root, newChild);
		CFRelease(newChild);
	}
	CFRelease(root);
}
2011-09-07 01:14:09.875 CFTree[1044:f203] release 2

This is where things go wrong; we only see one release log. How about if we remove the children with CFTreeRemoveAllChildren before releasing the root?

2011-09-07 01:19:37.394 CFTree[1122:f203] release 100
2011-09-07 01:19:37.395 CFTree[1122:f203] release 101
2011-09-07 01:19:37.395 CFTree[1122:f203] release 102
2011-09-07 01:19:37.395 CFTree[1122:f203] release 103
2011-09-07 01:19:37.396 CFTree[1122:f203] release 104
2011-09-07 01:19:37.396 CFTree[1122:f203] release 105
2011-09-07 01:19:37.397 CFTree[1122:f203] release 106
2011-09-07 01:19:37.397 CFTree[1122:f203] release 107
2011-09-07 01:19:37.397 CFTree[1122:f203] release 108
2011-09-07 01:19:37.398 CFTree[1122:f203] release 109
2011-09-07 01:19:37.398 CFTree[1122:f203] release 2

That’s a lot more like it! Now – these logs really only tell us what’s happening with the info payload of the trees, not the CFTrees themselves. For the sake of comfort, I decided to take a look at object allocations in Instruments. Based on the screenshots below, it is confirmed that destroying only the root tree isn’t sufficient for destroying the entire tree – you can see our 10 children tree’s lingering around.

What To Do

I’ve filed a bug report with Apple, you should too. In the mean time, this hiccup isn’t going to stop me from using CFTree. For now, I’m destroying the tree manually by traversing it (recursively) and using the CFTreeRemoveAllChildren function on each child tree starting with the deepest depth. The part in the documentation about child tree’s being retained by their parent and released when removed is accurate; following normal memory management will result in the expected behavior here. This solution isn’t nearly as clean and pretty as CFRelease(rootTree), but for now it will have to do.

*I say pseudo because it’s not a collection managed by a single object like an NSArray, but rather a collection made up of a relationship of “collection” objects.

Posted in Code | Tagged , , , , | 1 Comment

CALayer Internals: Contents

It’s right there in the CALayer documentation:

contents
An object that provides the contents of the layer. Animatable.

@property(retain) id contents

Discussion
A layer can set this property to a CGImageRef to display the image as its contents. The default value is nil.

There’s exactly one thing a developer can assign to a layer’s contents property: a CGImageRef. So why is the property declared to be an id?

Back Up a Second.

id is Objective-C’s general object type.  It’s like a void* for objects. We’ve already got kind of a problem here — how is a CGImageRef the same as an Objective-C object? — but short story, Core Foundation pseudo-objects (CFTypes) — and pseudo-objects that derive from CFType (like Core Graphics types) — are set up such that they satisfy the requirements of id. This is a prerequisite for, but not the same as, toll-free bridging. Maybe Jerry will write a post about that in the future!

Anyway.

It’s true that there’s only one thing a developer can write to a layer’s contents, but that’s only half of what a property does. If you read the contents back, you won’t necessarily end up holding a CGImageRef. If the layer has been drawn into, using delegate methods (displayLayer:drawLayer:inContext:) or subclassing (drawInContext:), you’ll actually get an opaque internal type called CABackingStore. This is, as the name implies, a pixel buffer holding the stuff you see in the layer.

Sounds like we have another problem! There’s no header file for CABackingStore; there’s nothing a well-meaning developer can do with it. Or is there? Although the documentation specifies that developers should set layers’ contents to CGImageRefs, they are actually perfectly happy to share generic contents. That means cloning a layer is as easy as layerB.contents = layerA.contents; no cast required, since they’re both type id! (…if they’re both in the same layer hierarchy*, which on iOS they almost certainly will be.)

Takeaway

The documentation doesn’t make it clear, but you can set a CALayer‘s contents property to either a CGImageRef, or the contents of another layer. When querying the contents of a layer, don’t expect to get back a CGImageRef, but do expect something that can serve as the contents of something else. Even if new types (internal or external) are added to the API, this will always hold true.

Posted in Explanation | Tagged , , , | 1 Comment

CALayer’s Parallel Universe

Ever tried to animate a UIView’s position?  It’s easy, using UIView animation class methods like animateWithDuration:animations: and friends.  Simply change the position inside the “animations” block, et voila, a pretty animation with the duration of your choice.

But have you ever tried to change that animation while it’s running?  Suppose you’re writing a simple application that animates a view to a point the user touches. The first one works fine, but after that, additional animation blocks will result in the view animating from the previous final location that it was supposed to go to — not from the location it’s very clearly occupying onscreen.

“Why Is That?”*

Now, I’m fudging a little bit for simplicity’s sake. One of the more complicated UIView animation methods allows options, one of which is UIViewAnimationOptionBeginFromCurrentState.  That fixes this problem in one fell swoop — as the name implies, animations will begin from the view’s current state, that being its position onscreen in our example, rather than the final state. But the larger question remains: why is such an option necessary at all? What’s going on behind the scenes? Join me as I draw back the curtain.

The Great Cover-Up

You may have heard somewhere along the way that UIViews are “backed” by CALayers. In practical terms, this means that CALayers actually handle the rendering, compositing, and animation of your view.  The UIView class is a relatively complex add-on that knows about things like user interaction (in the form of gesture recognizers), printing, and all the specialized things that UIView subclasses do.  But many of the core UIView methods — things that deal with view hierarchy, display, colors, even hit testing — simply call through to the underlying CALayer, which has similar methods.

Now that we know CALayer is doing all the work under the covers (which are themselves behind a curtain, as you’ll recall), we can talk about exactly how it does its dirty deeds.  What really happens when a view (that is, a layer) animates from point A to B?

The Parallel Universe

It’s not magic!  It’s even better: technology.  Two extraordinarily divergent things happen when you kick off an animation.  The animated property of the view (in our example, position) doesn’t animate at all!  It is immediately set to the final value. If you start an animation with a duration of a year, and in the next line of code read back the view’s position, you’ll get the position you’d expect the view to occupy a year from now. But that makes no sense — the view is onscreen, and it’s clearly not all the way over there. It doesn’t yet appear to have moved at all.  The view seems to be expressing two contradictory pieces of state.

(By the way, the fact that the view’s position jumps to the final value as soon as the animation begins is why the first example I talked about doesn’t work. When you start an animation, it’s internally expressed as “animate from A to B”, and the “A” is implicitly set to be the view’s current position. So when you animate from A to B, and then change it to C halfway through, the view already considers itself to be at B, although it does not appear so to the naked eye. But I suspect you may be more interested in the underlying question at this point! Let’s continue.)

If the view’s position changes instantaneously, but we can watch it travel across the screen, there must be some kind of trick taking place. And indeed, there is an incredibly pervasive trick. The secret is this: the view your code talks to is not the view on screen at all.  Indeed, no UI element you address is ever on screen! Instead, Core Animation creates a parallel view hierarchy, from UIWindow on down. What you see on screen is something like your view’s evil twin.

Did I blow your mind?

Theory

What Core Animation is doing is a low-level Model/View separation, just like the MVC pattern with which you’re familiar.  Wait, isn’t everything we’re talking about a view? Yes, we’re overloading the term here. Now we’re talking about model data about an object that happens to be a UIView, and the view of that model data. The model is the UIView you talk to — it contains the truth about the data (the position of the UIView).  The view is the parallel CALayer on screen — it’s a visual representation of the data. It can animate rather than moving immediately because just as in other MVC situations, the view renders the data however it feels appropriate; it’s not guaranteed to be a one-to-one representation.

This is cool to know, but it’s only of academic interest if you can’t access the parallel view hierarchy. Fortunately, you can! Not on the UIView level, but CALayer’s presentationLayer method gets you there. Terminology time: A layer’s “presentation layer” is the view I was talking about before. To move back and forth between the hierarchies, presentation layers have a “model layer” (accessed through the modelLayer method) that is, as you’d guess, the model — the layer you usually use in your code. Using these two methods, you can jump between the model and view layer hierarchies with ease.

Code

The practical upshot of this: the data of the presentation layer will reflect where things currently are on screen, as opposed to the model layer we’re used to. Suddenly, animating from a view’s current position is simple (although you will have to drop down into Core Animation to do it).  As a refresher, here’s the pertinent part of the example I started with. Remember, the idea here was to animate a view to the user’s touch, but it doesn’t animate cleanly once there’s another animation in effect.

- (void)viewDidLoad
{
	[super viewDidLoad];
	touchView = [[UIView alloc] initWithFrame:CGRectMake(0, 0, 40, 40)];
	touchView.backgroundColor = [UIColor redColor];
	[self.view addSubview:touchView];
	UITapGestureRecognizer *gr = [[UITapGestureRecognizer alloc] 
		initWithTarget:self action:@selector(tap:)];
	[self.view addGestureRecognizer:gr];
}

- (void)tap:(UITapGestureRecognizer*)gr
{
	[UIView animateWithDuration:1.f animations:
	 ^{touchView.center = [gr locationInView:self.view];}];
}

And here are the changes we have to make to use the presentation layer to run the animation from the current location:

- (void)tap:(UITapGestureRecognizer*)gr
{
	CGPoint newPos = [gr locationInView:self.view];
	CGPoint oldPos = [touchView.layer.presentationLayer position];
	CABasicAnimation *animation = [CABasicAnimation animationWithKeyPath:@"position"];
	animation.fromValue = [NSValue valueWithCGPoint:oldPos];
	animation.toValue = [NSValue valueWithCGPoint:newPos];
	touchView.layer.position = newPos;
	[touchView.layer addAnimation:animation forKey:@""];
}

What’s this all about? Just as before, we’re getting the gesture recognizer’s location to determine where we want to animate to. But where before we were depending on the UIView animation method to tell Core Animation to create an implicit animation, now we create our own, aptly called an explicit animation. (More posts on this distinction to come: for now, all that matters is that usually Core Animation will do the right thing for you. That’s an implicit animation.) The basic animation here simply takes a “from” and a “to”, which we fill in appropriately. (The fact that we have to wrap the CGPoints in NSValues is an unfortunate implementation detail.) We then set the final value, and right after, add the animation. It looks like a lot more code than before, but that’s really all that’s necessary, and this methodology can be used to do much more complex stuff than UIView animations are capable of. Check out the CAAnimation subclasses to see how you can do keyframe animations and lots more.

Problem Solved!

And a whole lot more besides. More on all of these concepts to come!

Posted in Explanation | Tagged , , , | 1 Comment

Integers in Your Collections (NSNumber’s not my friend)

Early on in the days of learning Cocoa, I remember coming across a situation where I had a bunch of integers that I needed to keep around, but wasn’t immediately sure about how to go about doing that using an NSArray. As is quickly made evident by the documentation, Cocoa collections pretty much all require their values and keys to be objective-c objects, which an integer (int, NSInteger, or NSUInteger) is not.

- (void)addObject:(id)anObject;
- (void)setValue:(id)value forKey:(NSString *)key;

Based on the plethora of Google results on the topic, it’s obvious that I’m not the only one who’s run into this situation; Sadly, nearly all of them indicate that, because collections require objects, the only solution is to wrap your integers with NSNumber. I’m writing this blog post to let you know that there ARE other ways.

(This post got a little long winded – if you don’t care about the academic conversation, go ahead and just skip to the code.)

Why You Should Care: NSNumber Comes With a Cost

Let’s start with why using NSNumbers might not be your best option: Objects are more expensive than scalars. In a nutshell, that’s all there really is to it; NSNumbers are often unnecessarily heavy for the job required of them. Objects require more memory to create than primitives, which in turn requires more CPU cycles to allocate. Another object cost, albeit a much smaller one, is the Objective-C dispatching required for the method calls needed to retrieve and compare basic values of an NSNumber.

Compare the following snippet of code: we are iterating through a loop 1 million times, and assigning our loop counter to a variable with two very different methods – using NSNumbers vs. using NSIntegers. (Logging code removed for brevity)

NSNumber *numberValue;
NSInteger intValue;

for (NSInteger i = 0; i < collectionSize; i++) {
	NSNumber *number = [NSNumber numberWithInt:i];
	numberValue = number;
}

for (NSInteger i = 0; i < collectionSize; i++) {
	intValue = i;
}
// 2.8 GHz i7 iMac
NSNumber 0.20776 Seconds
NSInteger 0.00208 Seconds

// iPad 1
NSNumber 3.76227 Seconds
NSInteger 0.00952 Seconds

Woah, assigning 1 million Integers is 100 times faster than creating and assigning 1 million NSNumbers on an iMac, and nearly 400 times faster on an iPad! In the land of performance optimization, a 100-400x improvement is almost always a win, even if it involves a small amount of extra code complexity.

A Cocoa Flavored Layer Cake

One of the most amazing (and simultaneously intimidating) parts of being a iOS/Mac developer is that for any particular problem, there exists a schmorgesborg of API ranging from high-level libraries like Foundation, down to straight C. For this occasion, our solution lies in the not-so-scary land that sits comfortably between Foundation, and C: Core Foundation. Technically, Core Foundation IS a C API, but a lot of the nitty gritty details of C have been abstracted away. When it comes to collections, this abstraction relieves us from needing to think about things like dynamically growing memory for an object with a capacity of an unknown length.

Anyone familiar with using Foundation should have very little trouble understanding Core Foundation, as much of the API is nearly identical – with the exception that it is C, and procedural based. In fact, the two are so closely related that many of the equivalent classes (e.g. NSArray/CFArray) only need to be typecast before they can be used interchangeably (this is called Toll-Free Bridging, and is something we have planned for a future article).

Below is an example that creates mutable instances of a CFDictionary and a CFArray.

CFMutableArrayRef array;
CFMutableDictionaryRef dictionary;
array = CFArrayCreateMutable(NULL, 0, &kCFTypeArrayCallBacks);
dictionary = CFDictionaryCreateMutable(NULL, 0, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);

NSString *aKey = @"ultrajoke";
NSString *aString = @"jerry";
CFArrayAppendValue(array, aString);
CFDictionarySetValue(dictionary, aKey, aString);

If you’ve been loving life in the realm of UIKit and Foundation, and haven’t spent any time with Core Foundation or any of the lower level API – it’s possible your head just went spinning as a result of this vastly different looking code. Trust me, it’s not so bad.

  • CFArrayCreateMutable and CFDictionaryCreateMutable – This is C, those are just the function names.
  • NULL – NULL is being passed for the allocator argument, and is the same as using kCFAllocatorDefault. This is something we can dive into more another time, but you know how in Objective-C you see things like [[MyClass alloc] init]? This is kinda like the alloc part. The important thing to know is that this argument impacts how memory is allocated, and you’re probably always going to want to use NULL.
  • 0 – This is just the capacity, the docs tell us that 0 means these collections will grow their capacity (and memory) as needed.
  • &kCFTypeArrayCallBacks, etc – These are pointers to structs of callback functions used for the values/keys, and are the kingpin of this whole article; more on them in a moment.

It’s All About The Callbacks

The sole reason we’ve moved to Core Foundation is that the functions for creating collection objects give us greater control over what happens when things are added and removed (notice I said things, not objects). This control is given by way of the callbacks we mentioned earlier; They vary depending on the collection type, but all of them fall into one of the 5 following basic types.

  • Retain Callback – Function called when a value is added to the array or dictionary, as a value or key.
  • Release Callback – Function called when a value is removed from the array or dictionary, as a value or key.
  • Copy Description Callback – Function called to get the description of a value. (Remember descriptions from ourprevious post?)
  • Equal Callback – Function called to determine if one value is equal to another
  • Hash Callback – Function used to calculate a hash for keys in a dictionary

Of the five types of callbacks, two sound very “object-y” in nature: Retain and Release. In fact, these are the two that need to change if we want to store integers in our collections; Integers aren’t objects, and don’t know anything about retain counts. According to the documentation for CFArrayCallBacks, CFDictionaryKeyCallBacks and CFDictionaryValueCallBacks, passing NULL to the retain and release callbacks results in the collection simply not retaining/releasing those values (or keys). What if we pass NULL to the other callback types? Again we turn to the documentation, and we find that they all have default behaviors that are used when NULL is provided. Description creates a simple description, Equal uses pointer equality, and hash is derived by converting the pointer into a integer.

If you’ve trudged all the way through this long winded post, you’re probably starting to see where I’m going with this, so let’s look at some code.

The Code

// Non Retained Array and Dictionary
CFMutableArrayRef intArray = CFArrayCreateMutable(NULL, 0, NULL);
CFMutableDictionaryRef intDict = CFDictionaryCreateMutable(NULL, 0, NULL, NULL);

// Dictionary With Non Retained Keys and Object Values
CFMutableDictionaryRef intObjDict = CFDictionaryCreateMutable(NULL, 0, NULL, &kCFTypeDictionaryValueCallBacks);

// Setting values
CFArrayAppendValue(intArray, (void *)79);
CFDictionarySetValue(intDict, (void *)5, (void *)10);
CFDictionarySetValue(intObjDict, (void *)5, @"ultrajoke");

// Getting values
NSInteger arrayInt = (NSInteger)CFArrayGetValueAtIndex(intCFArray, 0);
NSInteger dictInt = (NSInteger)CFDictionaryGetValue(intDict, (void *)5);
NSString *dictString = (NSString *)CFDictionaryGetValue(intObjDict, (void *)5);

CFRelease(intArray);
intArray = NULL;
CFRelease(intDict);
intDict = NULL;
CFRelease(intObjDict);
intObjDict = NULL;

Yeah, that’s really all there is to it; we simply pass NULL for the callback pointers, which prevents the collections from trying to call retain/release on the values assigned to it. It’s worth pointing out that there are some caveats to be aware of:

  • intArray and intDict are blindly storing pointer sized values, including pointers to objects, integers and booleans – nothing is retained/released.
  • The equal method for intArray and intDict uses “pointer comparison”, which is essentially the direct value that was stored. This means that while you can get away with storing a pointer to an object (that will not be retained), equality is determined by only the memory address.
  • Because the intObjDict Dictionary uses kCFTypeDictionaryValueCallBacks it’s values MUST be objects (either CFType or NSObject)
Posted in Code | Tagged , , , , , , | Leave a comment

Things I Learned at Siggraph

Our legions of dedicated fans (hi Mom) may have noticed a dry spell in the posts of late.  This is partly because I spent last week in beautiful Vancouver, B.C., attending the annual Siggraph conference.  In between time spent watching the year’s best computer animation and learning about morphological antialiasing, I picked up some stuff that’s specifically applicable to graphics development on iOS.  The following are my notes from “Beyond Programmable Shading”, a course about GPU utilization. Note, this is somewhat advanced stuff; if you’re not writing your own shaders, this may not be the blog post for you.

Background

Graphics implementations seem to run in cycles. We go from software graphics to fixed function hardware and back again. OpenGL was all about the fixed function, but with programmable shaders we’re right back in software. Of course there’s a tradeoff to either side; it’s all about flexibility versus speed.

Power

Working on a mobile device, our primary concern is power use. We’ve all seen games that drain the battery in a half hour of play time. The somewhat informed assumption is that doing parallelizable work on the GPU (graphics or otherwise) will always be a win. The reality is more complicated. CPUs take a higher voltage per core, but GPUs have many more cores. (Fixed function hardware, such as a floating point unit, is the cheapest to operate; it’s very fast and very inflexible). Offloading work onto the GPU is only a win if it takes less power overall — not just the power taken to do the work on those cores versus the CPU’s cores, but also the CPU power it takes to upload the data and read it back. For small tasks, this can dominate the time spent running code on the GPU.

Moving forward, let’s assume that we have good reason to run code on the GPU — like, say, graphics. We can’t control the voltage the chip takes when in use, but we can control how often it’s in use. Sounds like a no-brainer, but the best thing we as software developers can do to minimize power use is to minimize how long the chip spends running.

How can we do this?  First, cap your frame rate. The fewer frames per second you draw, the more time the chip spends idle. If you’re writing a graphically complex game that hits 45fps on a good day, you may not think about this; but you could be getting extremely high frame rates on easy content like menus. This can be even worse than expected, because working that fast can cause the chip to heat up, triggering throttling meant to avoid excessive temperatures. That means that when the user closes the menu and gets to the good stuff, you’ll no longer be capable of rendering at as high a frame rate as you’d like.

Now that your frame rate is low, optimize the time you spend rendering a frame. Same as before: the less time spent rendering, the more time the chip is idle. Don’t stop optimizing once you hit 60fps; further performance gains, combined with a capped frame rate, will really help power consumption.

Another way to keep the GPU idle is to coalesce work in the frame. Rather than computing the player’s position, then rendering the player, then computing the enemy’s position, the rendering the enemy, and so on, do all your rendering back to back. This will maximize the solid time the GPU can power off. It’s particularly important to keep the idle time in one large chunk rather than many small ones, because there is some latency associated with switching on and off parts or all of the chip.

Miscellany

There are plenty of ways to keep your GPU code fast; you’ve probably seen some of it if you’ve read anything about optimizing shaders. One common tip is to minimize branching. I learned why: when a GPU runs conditionals, it actually evaluates both branches — and not in parallel. For an if/else, it simply masks off writes on the cores that don’t meet the condition; runs the first branch on all cores; reverses the mask; and runs the second branch. That’s potentially a high price to pay! It pays to get clever with mix(), sign(), swizzling, and so on. Fortunately GLSL gives you lots of ways to avoid branching, if you’re willing to take the time to figure them out.

The most time-consuming operation in a shader is reading from memory. GPUs utterly lack the sophisticated caching mechanisms CPUs have; that’s the price for massive parallelism. GPUs are clever about hiding the stalls caused by memory loads by switching to work on other units (vertices or fragments, in our common cases); the trick is making sure there’s enough math for them to do to take up the time. Counterintuitively, a good strategy is often to recompute data rather than taking the time to load it. Those little cores are really fast, and reading from memory is really slow! You’d be surprised how many cosines you can calculate in the time it takes to read from your lookup table.

Bonus Notes on Vancouver

There are way more women than US-average wearing sheer tops. And a way higher incidence than I am used to of slight limps in both genders. Causation?

Posted in Philosophy | Tagged , , , , , | 1 Comment

Posted on by Joel Kraut | Leave a comment

Quick Tip: Drawing Right Side Up With Core Text

Anyone who has decided to explore using Core Text on iOS has probably noticed that everything is drawn upside down. This is because Core Graphics contexts that have been created with functions provided by UIKit (such as UIGraphicsBeginImageContext, or the drawRect method in a UIView) have a coordinate system with it’s origin (0,0) located in the top left corner. However, in the days before iOS, and when using a more traditional approach to creating a CGContext (CGBitmapContextCreate for example), the origin starts in the lower left corner. Because of its desktop origins and close ties to Core Graphics, Core Text expects the more traditional coordinate system; Without context adjustments, text is drawn as if it were mirrored vertically.

When I first started dabbling with Core Text, CGContextSetTextMatrix seemed like a reasonable place to start in order to fix this – it accepts a CGContextRef and a CGAffineTransform, and something like the following will indeed flip your text.

CGContextSetTextMatrix(context, CGAffineTransformMakeScale(1.0f, -1.0f));

Great, problem solved! Except that it’s not, especially if you plan on having more than one line of text using something like CTFrameDraw. In this case, just transforming the text matrix will flip your letters, but doesn’t adjust the direction in which the frame lays out line breaks. What you’ll notice is readable text, but with last line starting at the top.

Basically, you can think of the transform applied with CGContextSetTextMatrix as being applied to each individual letter as it is drawn. If you want to impact that way a segment of text is laid out as a group, then a transform needs to be applied to entire context. The following will both flip your letters, and lay text in the proper direction

CGContextTranslateCTM(context, 0.0f, contextHeight);
CGContextScaleCTM(context, 1.0f, -1.0f);

Mind you, transforming individual letters can still be fun! In the last view of the screenshot we’ve applied the following set of transforms to rotate each letter by 45 degrees, while maintaining proper layout and line breaks.

CGAffineTransform transform = CGAffineTransformIdentity;
transform = CGAffineTransformMakeRotation(45 * M_PI / 180.0f);
CGContextSetTextMatrix(context, transform);
CGContextTranslateCTM(context, 0.0f, rect.size.height);
CGContextScaleCTM(context, 1.0f, -1.0f);

Posted in Code | Tagged , , | 3 Comments

Localizing Arbitrary Strings the Scripty Way

I bet you saw my post about localizing US states and said to yourself, “Ha! That little sed script won’t do much for arbitrary strings!” You’re a jerk, but yes, you’re right. Before I give it away, does anyone see the problem with the previous script?

sed 's/@"[^"]*"/NSLocalizedString(&, nil)/g'

Let’s try it on some completely pseudorandom strings that I am about to pseudo-make up.

@"hey man"
NSLocalizedString(@"hey man", nil)
@"what's up"
NSLocalizedString(@"what's up", nil)
@"what\"s up"
NSLocalizedString(@"what\", nil)s up"

Uh oh. Clearly this simple script does not take escaped quotes into account. This is kind of a complex problem! We can’t just match strings of the type \", because there may be escaped backslashes in front of a real quote (ie \\"). So we have to match quotes preceded by an odd number of backslashes. And there could be any number of instances of that pattern, anywhere in the input, so we have to interleave it with the “every other character” match. Lucky for you I already did the work!

sed -E 's/@"([^"\\]*((\\\\)*(\\")*)*)*"/NSLocalizedString(&, nil)/g'

What the hell is this mess? First things first.

  • sed -E: the -E flag tells sed to use extended regexp, which allows for strings (in parentheses), not just individual characters.
  • @": match the beginning of an NSString.
  • [^"\\]*: match any number (*) of characters that are neither a double quote nor a backslash (this is confusing because we have to escape the backslash to keep sed from interpreting it).
  • (\\\\)*: match any number of paired backslashes, ie, backslashes escaped in the input.
  • (\\")*: match any number of double quotes immediately preceded by a backslash (escaped for sed, non-escaped in the input); that is, any number of escaped double quotes.
  • " match the closing double quote.

Now we can put some of these elements together to construct a more complex regular expression.

  • ((\\\\)*(\\")*)*: match any number of strings of the pattern “any number of escaped backslashes, followed by any number of escaped quotes”.
  • ([^"\\]*((\\\\)*(\\")*)*)*: and finally, match any number of strings of the pattern “any number of non-quote, non-backslash characters, followed by any number of double quotes preceded by odd numbers of backslashes”.

It’s critically important to remember that “any number” includes zero. That’s why this pattern can match the implied most complex pattern of input — something like @"a\\\"b\\\"c\\\"" — but still perform fine on input like @"hey man". Things that don’t occur in the input still occur zero times — just enough to match.

Okay, whatever! What’s the output look like?

$sed -E 's/@"([^"\\]*((\\\\)*(\\")*)*)*"/NSLocalizedString(&, nil)/g'
@"hey man"
NSLocalizedString(@"hey man", nil)
@"what\"s up"
NSLocalizedString(@"what\"s up", nil)
@"what\\\"s up"
NSLocalizedString(@"what\\\"s up", nil)
@"a\\\"b\\\"c\\\""
NSLocalizedString(@"a\\\"b\\\"c\\\"", nil)
@"\\\\\"
@"\\\\\"

Great! The pattern performs as expected on simple input, and on complex input catches the escaped quotes. It even fails on the last input, an invalid string which is never closed. Now we can localize not only input we know is free of exceptional conditions, but any arbitrary strings we might come across, all with the help of our two friends sed and regexp.

Posted in Code | Tagged , , | Leave a comment

Mistakes Were Made: Initialize Your Locals

“Mistakes Were Made” may or may not end up being a post series where we talk about actual things we have done wrong, and the lessons thereby learned.  The uncertainty is about whether revealing all this stuff will make us look unemployable.  We’re not, I promise.

One of the pleasant little details that make working in Objective-C such a joy is that instance variables are automatically zeroed out at creation.  That means that when you define a pointer in your object’s interface, you don’t have to explicitly set it to NULL in the init method — the compiler will take care of that for you, freeing your mental capacity for bigger and better things.  Languages with more strictly managed memory, like Java, will also do this, but looser languages like C and C++ will not.

Great, so what?

Problem is, you might get used to this and expect local variables to come zeroed out too.  They don’t.  I knew this, but was reminded of it the hard way recently.  A certain nameless application on the App Store has a table view that contains another table view in one cell.  The height for this outer cell is calculated thusly:

- (float)preferredHeight
{
	float height;
	int i;
	for (i = 0; i < numCells; i++)
    {
		height += cellHeights[i];
    }
    return height;
}

Whoops.  Anyone see the problem?  That’s right, height is used uninitialized — any old junk values that happened to be in there are added to the final count.  This is a particularly pernicious problem because on debug builds, the memory happened to be set up such that the initial value for height was somewhere around 9.71498046e-30 — for all practical purposes, zero.  Even on a release build tested locally, it was 14, easy enough not to notice.  It wasn’t until the app made it out into the wide world that I started to see real issues, but now, many people using that nameless application are seeing a cell that’s way taller than it should be.

What do I do?

There’s a warning for that!  Add -Wuninitialized to your build flags, or if you’re using Xcode, turn on the warning for “Uninitialized Automatic Variables” under Build Settings.  For some reason this is NOT the default for new Xcode projects!  I guess Apple expects us all to be smarter than I am.  There’s also -Wmaybe-uninitialized, which is more aggressive about warning when the variable may or may not have a value set, like cases in a switch statement that you know are impossible but the compiler doesn’t.  (Switch statements should always have a default!)

Of course, you should always initialize your variables anyway.  The warning should serve as a safety net, but clearly you can’t depend on it.  Given this, it might make sense to zero out your instance variables in your init methods, for consistency’s sake: it’s easier to do the wrong thing if sometimes it’s the right thing.  I know I would rather do too much zeroing than too little.

Posted in Code | Tagged , , | Leave a comment

CALayers v. CGLayers, or, Which Layer, Player?

What’s the Deal?

An evergreen source of confusion for developers new to graphics on iOS is the existence of multiple Apple-provided graphics frameworks, and multiple “layer” objects within those frameworks.  We’re told to use Core Animation for compositing and animation, and Core Graphics for two-dimensional bitmap drawing (as well as rarer things like low-level text layout and PDF rendering).  Core Animation’s basic class is the CALayer, and Core Graphics has its own CGLayer object.  Surely they are analogous!  Might we construct an SAT-style comparison?

CALayer : CA :: CGLayer : CG?

Despite one’s intuition, not even close.  This is just an unfortunate naming scheme that has wasted countless developer hours and spawned innumerable forum threads.  Let’s take a look at the differences.

CALayer

Yup, this one you’ll want to know about.  CALayer is one of the most important classes on iOS, right up there with UITableView.  The entire windowing system on iOS runs on top of Core Animation; this means that every single thing you see on screen lives in a CALayer.  They can be positioned, transformed in three(ish*) dimensional space, and a bunch of other neat stuff.  Perhaps most importantly, they can be filled with arbitrary bitmap content – and this is where the confusion sets in.  That bitmap content is often provided by Core Graphics!  When putting Core Graphics content into a CALayer, surely a CGLayer is the right way to go?

No.

Haven’t you been listening?

CGLayer

CGLayers are super cool drawing optimization objects – on the desktop.  Their main use is to cache drawing stuff – either bits or, for instance, PDF drawing commands – for re-use.  They make things like drawing a sprite for a game much faster, for a few reasons.  First, their contents can be stored on the graphics card, meaning that drawing them to the screen is super fast as compared to a bitmap stored in memory.  Second, they are constructed with a specific drawing context in mind, so they can optimize their contents for the format of that context.  And third, since drawing them into a context is so much faster than drawing an arbitrary bitmap, they can enable high-speed animation the Core Graphics way (re-rendering the screen each frame).

Thing is, these advantages don’t carry over to iOS.  When you set a CALayer’s contents, or draw into it, that bitmap is always stored on the graphics card.  That’s just the nature of Core Animation, as a framework built on top of OpenGL.  And practically speaking, there is really only one format you’ll be drawing into – that’s the nature of a closed ecosystem of devices with one optimal pixel format.  (If your app constructs PDFs on the device, this is not the blog post for you.)  As far as animation goes, well, it’s called Core Animation for a reason.  What it comes down to is that in iOS, using a CGLayer buys you nothing but additional complexity.

TL;DR

Don’t use CGLayers on iOS.

* a subject for another post!

Posted in Explanation | Tagged , , , | 2 Comments