Taking a quick look at the code it seems that the animation time for ball updates is fixed at 40ms using a Timeline with a single KeyFrame. So 25fps, half the refresh speed of any known desktop computer display.
brickbreaker/Config.java:40 public static final Duration ANIMATION_TIME = Duration.millis(40); Since this is well below the monitor refresh rate, and I suspect it isn't synced to the display refresh, you get ugly animation. I flipped it to 20ms for a quick test and the animation is much smoother, though there is still the occasional jitter due to not syncing with the display. I think a better implementation would use an AnimationTimer. I believe JavaFX tries to call them at the display refresh rate? Scott On Fri, May 31, 2013 at 10:13 AM, Richard Bair <richard.b...@oracle.com>wrote: > Have you tried to determine what the FPS is? My guess is that FPS is not > anywhere near the limit and it is the occasional stutter that is the > problem, but I'm not certain. Knowing that helps to point in which > direction to go. The fact that it runs pretty well on a PI is indication > that it isn't the framerate. > > Richard > > On May 31, 2013, at 4:26 AM, Scott Palmer <swpal...@gmail.com> wrote: > > Speaking of poor animation in Ensemble... > > Is anyone able to run Brick Breaker without choppy animation or poor > framerate performance on the ball? > > Now, I suspect the issue there is in the balls animation implementation in > the application rather than the JavaFX framework, as the bat moves smoothly > when I move the mouse, but the overall perception of JavaFX performance for > this demo app is not good. I would go so far as to say that Brick Breaker > has had the opposite effect it was intended too - simply because the > animation of the ball is not smooth. That's something that would run > smoothly on a Commodore 64,yet the last time I tried it (5 minutes ago) > with JavaFX 8.0-b91 on a quad-core 3GHz Windows 7 box with a decent NVIDIA > card, it didn't run as smoothly as I would expect. Just a single ball with > a shadow bouncing around the screen seemed to have a low framerate and the > occasional skipped frame. It just didn't look that great. > > The fact that Brick Breaker ships as a sample app from Oracle and it's > animation looks bad is harming JavaFX's reputation in my opinion. I think > it could run much better on the existing JavaFX runtime. The simple > animations in the Ensemble app run much smoother for example. > > > > Scott > > > On Thu, May 30, 2013 at 11:11 AM, Richard Bair <richard.b...@oracle.com>wrote: > >> >> > Then you mention Halo 5. I have to say the subtext here troubles me >> > greatly. If I read you correctly then you are saying that JavaFX is not >> > really suitable for games (at least anything beyond the demands of >> something >> > like Solitaire). As someone else pointed out, what is point of >> developing >> > 3D support in JavaFX if it is not really suitable for games? To say it >> is >> > not suitable for games implies that it is not really suitable for *any* >> > application that requires performant animations and visualisations. >> What >> > use then is the 3D API? >> >> That's not fair at all. There are a *lot* of enterprise use cases for 3D, >> and we get these requests all the time. Whether we're taking about 3D >> visualizations for medical or engineering applications or consumer >> applications (product display, etc), there is a requirement for 3D that are >> broader than real time first person shooters. >> >> Game engines often have very specialized scene graphs (sometimes several >> of them) as well as very specialized tricks for getting the most out of >> their graphics cards. When we expose API that allows people to hammer the >> card directly, then it would be possible for somebody to build some of the >> UI in FX and let their game engine be hand written (in Unity or JOGL or >> whatever). > > > > >> > However, I am not sure that having me preparing "reproducible" test >> cases >> > will actually help. In my experience, the Ensemble app already serves >> this >> > purpose. The choppiness I describe is *always* prevalent when I run the >> > animations and transitions in Ensemble (including Ensemble 8). The only >> > variation is in the degree of that choppiness. >> >> Then start with that, something absolutely dead simple like a path >> animation or rotate transition and lets figure out how to measure the >> jitter and get it into our benchmark suite. >> >> Richard > > > >