On Mon, 2 Sep 2024 15:37:38 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
> Q1: I see a lot of work in the code to handle reverse transitions. Is this > actually part of the CSS specification? Yes, it's a sizable chunk of the specification: https://www.w3.org/TR/css-transitions-1/#starting > Q2: Reversal detection seems very limited. If I change a value multiple times > within the duration of the animation, then reset it to its original value, > then I think the reversal code will not trigger. As an example, let's say I'm > animating scrolling. I'm at the top. I press page down once and then press > home. The value changes for example from 0 -> 20 -> 0 -- this triggers the > reversal code, and the animated scrolling will quickly return to its top > position. However, if I do 0 -> 20 -> 40 -> 0 (page down, page down, home), > then I think the reversal is not detected and I'm left with a very slow > return to the top position. There doesn't seem to be a one-size-fits-all solution for faster transition reversal. The CSS specification [acknowledges](https://www.w3.org/TR/css-transitions-1/#reversing) this: _Note that these rules do not fully address the problem for transition patterns that involve more than two states._ The algorithm as prescribed by the specification is one of several algorithms that were considered by the W3C working group back in 2013. It is clearly tuned for two-state application scenarios, and might simply not be the right solution for your problem. I've thought a lot about the problem, and while it may be possible to come up with an algorithm that covers more edge cases, that takes a huge toll on the complexity/maintainability budget. > > Q3: How does the user do calculations for properties that are being > interpolated? Let's say I have a simple system where the `+` and `-` change a > value by +10 and -10. So I press `+`; I read the current value, add 10 and > set it (say from 0 to 10). Now I press `+` again. Reading the current value > would get me some intermediate animated value. Adding 10 to this is not what > the user would expect (they would expect to go to 20, not to 15 if the > animation was only halfway completed). > > As an example, I've implemented (without CSS transitions) a smooth scrolling > system; this system tracks the target value to do the scrolling. Pressing 3x > page down in a row will go 3 pages down, no matter what the state of the > animation. With CSS transitions, should the programmer be aware of the > interpolation (which may be added later in CSS) and track their own "target" > value to make this work as you'd expect? I don't think this would work at all, because you're setting the value programmatically. You'll only get a transition if you let the CSS system set the value. If you do this, and then query the value of the property under transition, you will get an intermediate value. This simply wouldn't work otherwise, considering how JavaFX properties work. We can't have properties change their value over time, but when you look at them programmatically, they already have the target value. This behavior is also consistent with the [specification](https://www.w3.org/TR/css-transitions-1/#transitions): _Transitions are a presentational effect. The computed value of a property transitions over time from the old value to the new value. Therefore if a script queries the computed value of a property (or other data depending on it) as it is transitioning, it will see an intermediate value that represents the current animated value of the property._ ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2325065092
