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 <[email protected]>
> BTW, I wonder, why rotate layer produces different values for "origin"
> and "focus point", if focus point is exactly = 0.0?
> K
>
> 2013/7/29 Konstantin Dmitriev <[email protected]>:
> > 2013/7/29 Carlos López González <[email protected]>:
> >> 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
> already
> >> 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
> digit,
> >> so it looks like some sort of rounding error. This difference causes
> that
> >> 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
> reverse
> >> transformation of the width ducks but I really don't understand the
> reason
> >> of this change.
> >>
> https://github.com/synfig/synfig/commit/1efad88f9d2a8855df740e014f2cd00ce04502b4
> >>
> >> So, for this bug I think that it can be solved by changing the behavior
> of
> >> find_duck member by comparing the two points difference against a very
> small
> >> (i.e. 0.0000001) number instead of compare against 0.0. But that won't
> fix
> >> 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
> the
> >> problem.
> >> 3) It all that fails and takes so long to fix, elaborate the change of
> the
> >> 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/
>
>
>
> --
> 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!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Synfig-devl mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/synfig-devl
>
--
Carlos
http://synfig.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!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Synfig-devl mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/synfig-devl
