On Wed, 3 Jun 2026 15:28:29 GMT, Andy Goryachev <[email protected]> wrote:
> I wonder if the issue comes down to whether the chart animation represents > "non-essential animation which reduces discomfort for users who experience > motion sickness or vertigo" (`Scene.Preferences.reducedMotionProperty()`). In addition to the language used in the javadoc of the `reducedMotion` property, some users also choose to reduce motion because they perceive it to be [faster](https://www.reddit.com/r/LifeProTips/comments/1expslr/lpt_if_you_want_your_windows_11_pc_to_feel_a) and [snappier](https://news.ycombinator.com/item?id=33222434), so they don't have to wait a few hundred milliseconds for the animation to complete. This is a legitimate use case that we shouldn't dismiss. In general, I think that chart animations should also qualify as "non-essential". As a matter of fact, when I open up Monkey Tester with charts that have a large number of data points, I think animations add to the confusion instead of helping to resolve it, which can make them not only non-essential, but actively detrimental (and if the number of data points is too large, animations are pointless if it takes a few seconds to render even a single frame). > And also whether we want to disable animation to save CPU cycles / battery, > the original rationale for the `animated` property. If we add support to query the power-saver mode (most operating systems have it), then we should consider having it affect the `reducedMotion` property directly. The big difference between `reducedMotion` and a hypothetical `lowPower` setting is that the former unambiguously determines the _outcome_, whereas the latter is just a description of some system state, and the outcome depends on what the author thought would be associated with that system state. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2177#issuecomment-4614283774
