• Type: Bug
• Component: javafx
• Sub-Component: animation

• Priority: P3
• Status: Closed
• Resolution: Fixed

• Submitted: 2008-08-27
• Updated: 2015-06-16
• Resolved: 2011-03-30

Other
fx2.0Fixed

There may be a bit more we can do on the desktop. I've noticed for a while that when measuring FPS, we report ~62fps when it should be 60. I think this is due to still using millis in some places when we need to use nanos. 60Hz equates to a pulse every 16.666666 ms. In ms with integer roundoff, we end up using 16ms. A pulse every 16ms comes out to be 62.5fps, so I don't think we're running at a "true" 60Hz. A small difference, but enough to cause something funny, such as a skip/stutter, about once a second. Our Runnables/Futures are scheduled on a millisecond basis. A quick hack up of scheduling by the nanosecond gets us closer to 60Hz. FWIW, running with vsync and adaptive pulse also hits very close to a true 60Hz. 17-06-2009 This is one of the top priorities for Marina 05-02-2009 As indicated, there is a workaround by setting the com.sun.scenario.animation.pulse property. Since a proper fix seems to be dependent on RT-1088, which is beyond the scope of this release, I am setting the target release for post-1.0. 15-10-2008 The animation pulse can be changed by setting the com.sun.scenario.animation.pulse Setting to the desired frequency. For instance: com.sun.scenario.Settings.set("com.sun.scenario.animation.pulse", "200"); or -Dcom.sun.scenario.animation.pulse=200 10-10-2008 Filed RT-1088. 10-10-2008 In the past, we've had problems with timing irregularity which caused some pretty serious jitter. But the major issues were solved in Preview, as evidenced by perf.ClipTest in the Scenario-Demos Sandbox: Setting PULSE_DURATION to 60 hz total: 626 equal: 623 nequal: 3 0: 0 (0.0%) 1: 1 (0.2%) ... 14: 2 (0.3%) 15: 379 (60.5%) 16: 242 (38.7%) 17: 1 (0.2%) ... >= 35: 1 (0.2%) >98% of pulses are being delivered right on time at 15-16ms. This is true with pulse rates even down to 5ms (200Hz): ... 3: 20 (1.0%) 4: 1567 (78.6%) 5: 371 (18.6%) 6: 34 (1.7%) ... It might be worth writing an FX version of ClipTest, to make sure that timing irregularities aren't being introduced farther up the stack. 98% timing precision is pretty darn good considering where we have been before. The problem is that we're still subject to the scheduling whims of the OS, and are "flying blind" with respect to being in sync with the monitor refresh. Even 2% error at 60Hz is about 1 bad pulse per second. Is this about how often a "jitter" happens? By default, we run the animation clock at the same frequency as the screen refresh. However we aren't sync'd to screen's refresh, which means that even small irregularities in timing can cause trouble: a slightly late pulse can mean that 0 animation frames happen in one screen refresh (possibly followed by two frames happening on a following screen refresh). An animating object may appear to "stick" for a frame. A slightly early pulse should be okay in and of itself, as the animation engine will just wait for the next pulse to do the next frame of the animation. FWIW - determining for sure if this is really what's happening is a bit ad hoc: correlating visual animation jitters with instrumentation of "out of range" clock pulses is pretty imprecise. And even then you don't know if bad clock pulse happened at just the wrong time wrt the screen refresh to produce a "jitter". One thing that definitely helps smooth out animation is to increase the frequency of the animation clock. I've confirmed this with the submitter. Increasing the clock to 2x (or even 3x) the screen refresh rate makes it very likely that we'll receive at least one clock pulse on every screen refresh. However, this comes with a cost of CPU usage. Some data from the Bounce sample: 60Hz anim pulse: ~5-8% CPU 120Hz anim pulse: ~10-15% CPU 200Hz anim pulse: ~15-20% CPU This would also seem to absolve GC of being the culprit - a higher clock speed would generate as much or more garbage, yet the animation looks smoother. I think the real answer here is that we need vsync-driven animation. It's the only certain way to stay synchronized with the monitor, and would provide a precise timing source that would be hard to achieve otherwise on the multitasking OSes we run on. I'll file a bug for this feature. 10-10-2008 Looks like a performance issue. Assigning to Brent to take a look at... 15-09-2008