[openjdk/jfx] 8234712: Add pivot properties for scale and rotation in Node, ScaleTransition and RotateTransition (#53)

Nir Lisker nlisker at gmail.com
Tue Dec 17 00:01:14 UTC 2019 

Thanks for the input Michael,


> Introducing two separate centers for rotation and scaling is, to my
> opinion, just academic without any practical use-case and in the end much
> more complicated for the user.


I have a practical use case in my app. I assume that the people who
requested these enhancements also had one. I also don't think that it's
"much" more complicated as it just aligns with the existing transforms
functionality.

1. Three doubles always use their full space even if you don't need them.


No sure what you mean by "full space". Properties are initialized lazily,
so if a value was not set, the reference is null, and the default pivot
value applies (computed center).

2. Using Double.NaNs as a switch between computed and user-provided
> center is just confusing and error-prone.


It is confusing indeed, but I don't think it's error prone as you'd be hard
pressed to fall on a NaN value for a pivot point as a result of a
computation. We could use one of the INFINITY values instead if it's
better. We should create a constant, public static final double CENTER =
Double.NaN (placeholder name), just like Animation.INDEFINITE = -1,
Region.USE_PREF_SIZE
= Double.NEGATIVE_INFINITY, Region.USE_COMPUTED_SIZE = -1 etc. It's not
ideal, but it's a solution for allowing the user to revert to the default
behavior without additional boolean properties.


> What would be the meaning of setting x to some value but leaving y and z
> as NaN?
>

That y and z are the computed center (Node computes the x, y and z of the
center separately to being with), and x is the user value.

I bet most users will forget to set the Z-value anyway if they are thinking
> 2D.


They wouldn't need to, it will behave as it does now (overall, backwards
compatibility is guaranteed).


> A simple null value is much easier to handle and explain.


Yes, it's certainly an advantage of a Point3D, which was my initial
implementation. The main issue with it, I would say, is that it's difficult
to bind to.

- Nir

On Mon, Dec 16, 2019 at 1:36 PM Michael Paus <mp at jugs.org> wrote:

> I don't think there are clearly right or wrong answers to all these
> questions,
> so I would just like to provide a view thoughts on this.
>
> The governing principle should be a principle of "least surprise" from a
> users
> point of view. That means we should not make things more complicated as
> they already are and should always keep the practical use-cases in mind.
> If you need full flexibility, you can always use the explicit transforms.
>
> We currently have the notion of the "Node's center" which is used for
> scaling
> and rotation and I think we should stick to that. The documentation later
> explains that "The pivot point about which the rotation occurs is the
> center
> of the untransformed layoutBounds." which is a completely arbitrary
> decision
> because, e.g., from a mathematically point of view the geometric center
> of the
> node would seem to be more natural but is more difficult to compute for
> general
> shapes. So, we should just extend this scheme in such a way that the
> user can
> replace the single computed center with a single user-defined center
> specified in untransformed coordinates. Introducing two separate centers
> for rotation and scaling is, to my opinion, just academic without any
> practical
> use-case and in the end much more complicated for the user.
>
> I would also specify this center point as a Point3D for two reasons:
> 1. Three doubles always use their full space even if you don't need them.
> 2. Using Double.NaNs as a switch between computed and user-provided center
>      is just confusing and error-prone.
>      What would be the meaning of setting x to some value but leaving y
> and z as
>      NaN? Would you implicitly set them to 0.0 or use the computed values
> or
>      would you discard this user setting completely and use all the
> computed
>      values if any of the components is NaN? I bet most users will
> forget to set the
>      Z-value anyway if they are thinking 2D. A simple null value is much
> easier
>      to handle and explain.
>
> Just my two €ent.
>
> --Michael
>
> Am 16.12.19 um 03:06 schrieb Nir Lisker:
> > Replying on the mailing list to the questions raised on GitHub.
> >
> > The state of whether to use the computed center pivot or the value of the
> >> pivot attribute is implicit with no way for an application to know
> which it
> >> is, and no way to set it back to using the computed center (i.e., the
> state
> >> is sticky once you set it). Perhaps if you defined a null value as
> meaning
> >> "computed center" then an app could at least reset it to the "computed
> >> center" state, although there would still be no way for the app to know
> >> that it was in that state.
> >>
> > In the JBS issue <https://bugs.openjdk.java.net/browse/JDK-8234712> I
> > alluded to this in point 5. I think that null should represent the
> default
> > (node center). However, if we use 3 doubles instead of a Point3D we might
> > need to use Double.NaN for this instead, which would also be the default
> > for this case. The docs will explain this.
> >
> > Do we need separate properties for scale pivot and center pivot?
> > I say yes, otherwise the enhancement will be very limited. I think of
> this
> > enhancement as adding pivot control to Rotate/Scale transitions, and
> adding
> > them to Node is a necessary (and desirable) step.
> >
> >     ... you need to worry about what coordinate space the rotation pivot
> is
> >> defined in. Perhaps if the rotation pivot were defined in unscaled
> space,
> >> it might work.
> >>
> > Isn't it already? If I set the rotation pivot to the edge of the node,
> then
> > scale it down, then rotate, the rotation pivot would be outside of the
> > node's boundaries. In scaled space it would still be on the edge. Or did
> I
> > misunderstand you? In any case, I don't think that there's a single
> correct
> > answer here.
> >
> > Should the pivot be specified as a Point3D or 3 separate doubles?
> Separate
> >> doubles... there would be no out-of-band null value to use
> >
> > See my point above about Double.NaN.
> > The doubles vs Point3D is an important choice. We might want to look into
> > the future even where Point3D (and 2D) could be made into an Inline class
> > with Valhalla, which will help with the performance aspect. Binding to
> one
> > of the coordinates is sill a problem there, however.
> >
> > On Sat, Dec 14, 2019 at 6:25 PM Kevin Rushforth <
> notifications at github.com>
> > wrote:
> >
> >> This will need discussion on the openjfx-dev mailing list. Here are the
> >> questions that need to be resolved:
> >>
> >>     1.
> >>
> >>     The state of whether to use the computed center pivot or the value
> of
> >>     the pivot attribute is implicit with no way for an application to
> know
> >>     which it is, and no way to set it back to using the computed center
> (i.e.,
> >>     the state is sticky once you set it). Perhaps if you defined a null
> value
> >>     as meaning "computed center" then an app could at least reset it to
> the
> >>     "computed center" state, although there would still be no way for
> the app
> >>     to know that it was in that state.
> >>     2.
> >>
> >>     Do we need separate properties for scale pivot and center pivot? A
> >>     single pivot property would be easier to define, but wouldn't allow
> you to
> >>     set it from a RotationTransition and a ScaleTransition if you wanted
> >>     to apply both to the same Node. With two separate properties, as you
> >>     have defined it, it is more flexible, but you need to worry about
> what
> >>     coordinate space the rotation pivot is defined in. The current
> transform
> >>     chain looks like this:
> >>
> >> T(layout+translate) * T(pivot) * T(rot) * T(scale) * T(-pivot)
> >>      * transform[0] * transform [1] ...
> >>
> >> Perhaps if the rotation pivot were defined in unscaled space, it might
> >> work. The transform chain would then look like this:
> >>
> >> T(layout+translate) * T(pivotRot/scale) * T(rot) * T(-pivotRot/scale) *
> T(pivotScale) * T(scale) * T(-pivotScale)
> >>      * transform[0] * transform [1] ...
> >>
> >> In any case, you need to think about the implications of having one of
> >> scale or rotate being set explicitly and the other being the computed
> >> center.
> >>
> >>     1. Should the pivot be specified as a Point3D or 3 separate
> doubles? I
> >>     can see pros / cons of either approach. Separate doubles are more
> >>     consistent with the the pivot values in the Rotate and Scale
> Transform
> >>     objects, and are easier to using in binding. On the other hand,
> there would
> >>     be no out-of-band null value to use (see issue 1 above), so you
> would
> >>     need a boolean property for each of scale pivot and rotation pivot
> to
> >>     indicate whether the computed value or the value of the pivot
> properties
> >>     should be used. I don't think that the fact that the rotation axis
> is
> >>     defined as a Point3D should have any bearing on whether the pivot
> >>     should be so defined. I'd probably lean towards separate doubles.
> >>
> >> —
> >> You are receiving this because you authored the thread.
> >> Reply to this email directly, view it on GitHub
> >> <
> https://github.com/openjdk/jfx/pull/53?email_source=notifications&email_token=AI5QOM6KRPRRP7VS5OUH6QLQYUCF7A5CNFSM4JR3TYY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG4GCGI#issuecomment-565731609
> >,
> >> or unsubscribe
> >> <
> https://github.com/notifications/unsubscribe-auth/AI5QOM4UKZQVDEN2A2HYYETQYUCF7ANCNFSM4JR3TYYQ
> >
> >> .
> >>
>
>

More information about the openjfx-dev mailing list