I wonder that too!! And that's why I want to fix it from the root cause ^__^
It might be that doing a transformation, then undoing it back and then redo
the transformation, could deliver some rounding error. That's why I suspect
about the commit I mentioned in my other post...
2013/7/29 Konstantin Dmitriev <ksee.zelgadis@...>
> BTW, I wonder, why rotate layer produces different values for "origin"
> and "focus point", if focus point is exactly = 0.0?
> 2013/7/29 Konstantin Dmitriev <ksee.zelgadis@...>:
> > 2013/7/29 Carlos López González <genetita@...>:
> >> Hi!
> >> I've been researching a bit about this commit and have some conclusions:
> >> 1) It only happens when there is a Rotate layer above (possibly you
> >> know). It doesn't happen with Zoom, Stretch or Translate above.
> >> 2) In 0.64.0 it doesn't happen.
> >> 3) Executing the code step by step, the problems seems to be that the
> >> transformed position of the handle origin is not the same than the
> >> transformed position of the focus. The difference is about in the 7th
> >> so it looks like some sort of rounding error. This difference causes
> >> the find_duck member doesn't find two ducks at the "same" place and
> >> sometimes it finds the focus and other the origin.
> >> 4) I've found that in this commit, there is a change of the way the
> >> transformed point is calculated. This commit was included to allow
> >> transformation of the width ducks but I really don't understand the
> >> of this change.
> >> So, for this bug I think that it can be solved by changing the behavior
> >> find_duck member by comparing the two points difference against a very
> >> (i.e. 0.0000001) number instead of compare against 0.0. But that won't
> >> the root cause of the problem.
> >> So my idea is this:
> >> First give a try to fix the root cause of the bug by doing:
> >> 1) A revert of the commit from the point 4) above on the part of the
> >> get_trans_point_origin member.
> >> 2) If this fails, try a git bisect to find the commit that is causing
> >> problem.
> >> 3) It all that fails and takes so long to fix, elaborate the change of
> >> find_duck member I mentioned as a workaround.
> >> Opinions?
> > Looks good. In any case, comparing against the 0.0000001 is not the
> > worst workaround. At the end, if difference of two ducks is less than
> > 0.0000001, then from user point of view they are at the same place
> > (because I hardly can imagine pointing device giving the precision
> > close to 0.0000001 when clicking on the screen). ^__^
> > K.
> > --
> > http://morevnaproject.org/
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> Synfig-devl mailing list