Wow great find. AnimationTimer wasn't around when BrickBreaker was written (somewhere in the JavaFX 1.0 timeframe iirc) and probably the author was working around really bad performance at the time by trying to get the ball to do less work!
I will take a look here in a second. I suspect there will still be the occasional stutter (and we need to track that down), but 25ms is a really odd number to be sure. Richard On May 31, 2013, at 8:16 AM, Scott Palmer <swpal...@gmail.com> wrote: > 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 >> > >
