As I see it, our animation API can be viewed as four levels:
- simple transitions
- custom transitions
- timelines
- AnimationTimer
If you know how an object will move, you should be fine with the upper
two. If you want to react on user actions you can still adjust the
transitions in input event handlers (to change directions), you can also
have property listeners that will be called every time the transition
updates the property which is every frame. The benefit of the
transitions is that they compute the time-based interpolation for you
and you don't need to do that manually (avoiding the mentioned issue
with the patch). If there is something complicated that needs to be done
in each frame and the above is not enough, then yes, AnimationTimer may
be the right way. I agree this may be the case for many video games, but
I don't think it justifies for using the low-level API where it is not
necessary. If this demo is about "how to write brick breaker", then
diving right to the deepest API level is not really educative. If it is
about "how to write a typical video game", then I think we should rather
produce a typical ShootEmUp game where this API usage would fit more
naturally. I realize it is easy to say but hard to find time for it..
With regards to the pulses - pulse is a sync from scenegraph to render
tree - it tells to the render tree how the current scenegraph looks like
and render tree then keeps displaying that state until the next pulse.
Scenegraph also does some updates during the pulse (yes, layouts fall
into this category). By default on desktop the pulses have an upper
limit of 60fps (means 60 pulses per second), without any connection to
actual display refresh rate. I think (and I'm not certain here) that the
pulse requests are there only to make sure the next pulse is scheduled
(we don't schedule pulses if nothing changes).
Pavel
On 3.6.2013 15:30, Scott Palmer wrote:
In this particular example you may be right. The trajectory of the
ball can be pre-computed for at least the entire length of the
straight line that it will travel in. You could go a couple bounces
ahead even, to the point where the ball would get back to the bottom.
However, that is definitely not the typical case for a video game.
Per-frame or per-update computations are the norm for video games.
Change the game style to a shoot'em up where every frame you need to
determine collisions, the direction of the player or enemy may change
etc, and it actually isn't any simpler trying to use a pre-computed
timeline. The calculation of such a timeline would be more work. I
think in the general case for a video game, AnimationTimer is more
likely to apply than other techniques. It fits the basic pattern
commonly used and therefore makes better sample code. There is a
small problem with Richard's patch though...
I would like to know a little more about the relation of the "pulse"
to the refresh rate. I know that there are places in JavaFX where a
"pulse" is requested or maybe forced. Presumably to trigger
calculations related to general scene graph layout issues. (I find
often that the layout of the scene is wrong actually - that is when I
do actions that force a refresh I will see the layout adjust to a
state where it clearly should have been in the first place.)
One would think that in general one pulse per display refresh would be
the minimum though. Anything less means the animation will not be
smooth, anything more shouldn't cause problems. The key is that the
"now" time is used to update any time-based values. I think Richard's
patch to BrickBreaker is actually incorrect in this regard, as I don't
see the actual time passed being used in the calculations.
Scott
On Mon, Jun 3, 2013 at 7:56 AM, Pavel Safrata
<pavel.safr...@oracle.com <mailto:pavel.safr...@oracle.com>> wrote:
Hello,
I'm a bit behind with this thread but I want to make a few
comments on AnimationTimer as there is a hidden message in the
discussion that AnimationTimer is the way to go.
First, AnimationTimer is called in each pulse, which doesn't have
much in common with display refresh rate (if I understand the term
correctly). More importantly, AnimationTimer is kind of extreme
low-level animation API that should not be needed in vast majority
of cases. I think a better way to code BrickBraker would be to use
a single TranslateTransition for the entire straight part of the
ball's trajectory; it would automatically compute the
interpolation and sync the position on every pulse, which should
have the same result as doing everything manually with the
AnimationTimer (but expressed in simpler code).
Regards,
Pavel
On 31.5.2013 22:45, Richard Bair wrote:
I pushed the fix to graphics. Thanks Scott for tracking that
down! It looks 10x better.
Richard
On May 31, 2013, at 9:25 AM, Richard Bair
<richard.b...@oracle.com <mailto:richard.b...@oracle.com>> wrote:
Patch attached to
https://javafx-jira.kenai.com/browse/RT-29801. I'm not
seeing any stutter on my Mac, interested to hear the
experience on Windows.
Richard
On May 31, 2013, at 8:44 AM, Richard Bair
<richard.b...@oracle.com <mailto:richard.b...@oracle.com>>
wrote:
Ya I did the same, am now adjusting it so the factor
by which things move is better.
Richard
On May 31, 2013, at 8:32 AM, Scott Palmer
<swpal...@gmail.com <mailto:swpal...@gmail.com>> wrote:
Richard, I suspect you made a typo. I think you
mean "*40*ms is a really odd number..." (it was 25
FPS, not 25ms)
I quickly hacked it to use AnimationTimer and the
animation is very smooth now. Though I didn't
make the required changes to adjust the speeds
based on the refresh rate. The quick conversion
to AnimationTimer is trivial.. but going through
and adjusting all the translations and increments
to be relative to the time between consecutive
frames is something I don't have time for.
Cheers,
Scott
Scott
On Fri, May 31, 2013 at 11:21 AM, Kevin Rushforth
<kevin.rushfo...@oracle.com
<mailto:kevin.rushfo...@oracle.com>> wrote:
Btw, there is a JIRA issue filed against
BrickBreaker specifically:
https://javafx-jira.kenai.com/browse/RT-29801
Richard Bair 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
<mailto: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
<mailto: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
