When I discussed how to resize `UIPickerViews`

last year, I touched upon the fact that a `UIView's`

`transform`

property is rather unusual; according to the documentation:

The origin of the transform is the value of the center property, or the layer’s anchorPoint property if it was changed. (Use the layer property to get the underlying Core Animation layer object.)

This turns out to be something of a hassle when trying to reason about transformations. Fortunately, a little math can sort things out.

### Math

It’s probably worth pointing out that the affine transformations used in computer graphics aren’t arbitrary collections of numbers; they are matrices which are applied to vectors which represent points in a coordinate system. The results of these computations represent points in a new coordinate system. For instance, points specified in the coordinate system of a `UIView`

are transformed into the coordinate system of its superview, and its superview’s superview, and so on, ultimately being brought into the coordinate system of the physical screen.

The Mac universe seems to consistently use row vectors, so, given the definition of a `CGAffineTransform`

, a point is transformed like this:

```
[a b 0]
[x' y' 1] = [x y 1] * [c d 0]
[tx ty 1]
```

that is:

```
x' = x*a + y*c + tx
y' = x*b + y*d + ty
```

### The Problem

Unfortunately, if you just grab the `transform`

of a `UIView`

and invoke `CGPointApplyAffineTransform()`

to transform a point, you’re very likely to get the wrong answer. More precisely, if you were to execute:

`CGPoint np0 = [aView.superview convertPoint:op fromView:aView];`

and:

` CGPoint np1 = CGPointApplyAffineTransform(op, aView.transform);`

for an arbitrary point `op`

, you would likely get two different results for `np0`

and `np1`

.

This happens because the `transform`

property is a big fat lie. More specifically, that business about the “origin of the transform [being] the value of the center property” is nonsense; the origin of any transform is the origin of the initial coordinate system. What’s really happening is that prefix and suffix transforms are being concatenated with the matrix stored in the `transform`

property before it is applied to any points. If you want to reason closely about the transforms being done by the system, you have to take these “hidden” transforms into account.

### Wrappers

When converting points from a `UIView's`

coordinate system to that of its parent, the system effectively moves the point at the center of the `bounds`

rectangle to the origin of the initial coordinate system, then applies the `UIView's`

`transform`

, then moves the point at the origin of the transformed coordinate system to the `UIView's`

`center`

property. (Remember that `center`

is a point in the superview’s coordinate space.)

In code, it looks something like this:

```
CGAffineTransform MakeEffectiveTransform(UIView* subView)
{
CGRect b = subView.bounds;
CGAffineTransform t0 = CGAffineTransformMakeTranslation(-b.origin.x-b.size.width/2, -b.origin.y-b.size.height/2);
CGAffineTransform t1 = CGAffineTransformMakeTranslation(subView.center.x, subView.center.y);
return CGAffineTransformConcat(t0, CGAffineTransformConcat(subView.transform, t1));
}
CGPoint ConvertPointToSuperview(CGPoint p, UIView* subview)
{
return CGPointApplyAffineTransform(p, MakeEffectiveTransform(subview));
}
```

### Lying

This analysis lets us derive a simple function that will convert “proper” transformations (i.e. matrices that give us the right answers when multiplied with row vectors) into matrices suitable for assignment to `transform`

properties. We just need to apply the inverses of the prefix and suffix transforms, s.t. the prefix and suffix will be canceled out when applied. Something like this would work:

```
CGAffineTransform MakeAssignableTransform(CGAffineTransform t, UIView* subView)
{
CGRect b = subView.bounds;
CGAffineTransform t0 = CGAffineTransformMakeTranslation(b.origin.x+b.size.width/2, b.origin.y+b.size.height/2);
CGAffineTransform t1 = CGAffineTransformMakeTranslation(-subView.center.x, -subView.center.y);
return CGAffineTransformConcat(t0, CGAffineTransformConcat(t, t1));
}
```

### Why Should You Care?

The truth is, most of this stuff will make absolutely no difference to you most of the time. But, one day, you may find yourself trying to debug some bizarre animation problem, and digging into the underlying `transforms`

on that day, it will be helpful to bear in mind that you can’t just run points through them and expect to have the results make any sense.

I’m still trying to decide whether I think this was a clever move on AAPL’s (NeXT’s?) part. I guess you need something like this if you want to have a distinct `center`

property … I don’t much like it, though.