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
>
>
>
>
