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