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