Re: Coordinate conversions in CALayer
Re: Coordinate conversions in CALayer
- Subject: Re: Coordinate conversions in CALayer
- From: Graham Cox <email@hidden>
- Date: Thu, 24 Jan 2013 19:19:16 +1100
On 24/01/2013, at 12:42 PM, Quincey Morris <email@hidden> wrote:
> This sort of thing drives me nuts too. You have to simplify the problem.
>
> 1. In the scenario where bounds.origin is (0,0) and the anchor point is (0,0) -- which should be be a very ordinary scenario to set up, even if you have to abuse your app to make it so -- the third transformation has no effect. If -- another ordinary scenario (I'd hope) -- the layer transform is the identity, the second transformation has no effect. So start with those scenarios in effect. Can you make it work with *just* the first translation doing something? That will incidentally settle the sign question once and for all.
>
> 2. Once you have that working, start using a non-identity layer transform, preferably something very easy like a 90 degree rotation, or a 50% scale, or a reflection about a vertical axis. If you don't get the right answer, it *should* be obvious why not. Then try it with a 30 degree rotation to check you didn't just solve it for a special case.
>
> (If you're depending on seeing what draws to find out if you got it right, try something like a 95% or a 105% scale. One or other of those would likely still draw something you can recognize, and tell you whether the error is a mis-translation or a mis-scale, and in which direction.)
>
> 3. After you get that far, I can't imagine it would be difficult to get the last transformation right. Even so, do it in 2 parts, first with a non-zero bounds origin, then second with a different anchor point.
>
> As to why the methodology isn't precisely parallel in the 2 cases, I dunno, but I suspect it's because in one case you're drawing untransformed geometry into a transformed drawing space; in the other case, you're drawing transformed geometry into an untransformed drawing space. Those two things might be as equivalent as you expect.
>
> But you've probably thought this all through already ...
Thanks Quincey, that's pretty much what I've been doing, just build it step by step...
The problem for me with this is that even once it works it's still voodoo - my understanding hasn't improved.
I've made some progress, in that I managed to make the two code snippets work the same, by changing this line:
tfm = CGAffineTransformConcat( tfm, layer.transform );
to this:
tfm = CGAffineTransformConcat( layer.transform, tfm );
I do appreciate that matrix concatenation isn't commutative, but it's still not clear to me why it needs to be this way round when the equivalent line when manipulating the CTM is:
CGContextConcatCTM( ctx, layer.transform );
This suggests that internally, this call passes the CTM as the second parameter, not the first. If so, then the documentation could do well to spell that out, since matrix order is so important. If not, then my understanding is still off, which does not surprise me.
Following on from this discovery, I've got my code to work as it should, but there's still way too much voodoo there for comfort. For example, if I "round trip" a point through the super to layer transform and then back, I need a slightly different series of operations than I do to round trip a rect in the same way. Still progress is progress, and that's better than being stuck.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden