On 24/01/2013, at 12:42 PM, Quincey Morris
<quinceymor...@rivergatesoftware.com> 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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
