Can you make the changes and verify the results? BrickBreaker and the
other samples are supposed to be "how to" examples for people to emulate.
Steve
On 03/06/2013 7:56 AM, Pavel Safrata 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>
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>
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> 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> 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>
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
