On 2010-09-02, at 10:56, Max Carlson wrote:
> Yeah I see whats going on. Lzviewlinkage needs to take scaling into account
> but not the x of blueview. This happens to work out with the canvas since
> its x/y are almost always 0. Going the other direction is just completely
> broken.
>
>>>> assertEquals((yellowview.x+redview.x)/(- blueview.xscale),
>>>> blueview.getAttributeRelative('x', redview), "blue x in red")
>
> According to my calculations, this should be 100: (yx + rx) * bs or (10 + 40)
> * 2. I have something hacked in that works, but I'm doing some
> cleanup/simplification to the code to make this easier to understand in the
> future.
On reconsideration, I think we are both wrong. I think it should be -50.
The question being asked is "how far would I have to move in x in the redview's
coordinate system to get to blueview's current x. Blueview's x=0 is at
absolute 10. Redview's x=0 is at absolute 110. Redview is scaled by a factor
of 2, so if I move x=-50 in redview, I should end up at absolute 110 + (-50 *
2) === 10, which is where blueview's x is.
Looking at it another way, since the dimensions of views read out as their
unscaled values, when you are calculating a relative attribute, you only need
to factor in scaling if the views being compared do _not_ share the scaling
factors. In this case, yellowview and redview are both governed by the same
scale factor (of blueview) so it's not even part of the equation.
> Oh and, math is hard :p
Hey, I was willing to take this bug, but you seemed to want it. Be careful
what you wish for. :P
---
The thing that still mystifies me:
blueview.width === 100
but in absolute terms, it is 200 pixels wide.
blueview.x === 10
and that's were it is in absolute terms, 10 pixels down.
How do we reconcile that?
