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