The link didn't work for me, is there another link? (It came up with a page of videos, the top one being video.3gp)
Richard On May 31, 2013, at 8:46 AM, Daniel Zwolenski <zon...@gmail.com> wrote: > Just on the topic of what should we expect performance/animation/graphic > wise, are there technical limitations why jfx can't achieve this exact level > of quality in animations: > http://m.youtube.com/#/watch?v=-fNg-qZcIdY&feature=youtube_gdata_player&desktop_uri=%2Fwatch%3Fv%3D-fNg-qZcIdY%26feature%3Dyoutube_gdata_player > > This is more or less the style of animation that I'd want to use jfx for. > > So if I wrote the code for this and then ran it side by side with the video > how far off should the two be? > > I get that this is a pre-rendered video so it has some advantages but the > video does not use rapid redraws or complicated particle effects, shadows, > reflections, etc, like in a FPS game. How close should we expect jfx to get > to this and which bits are not achievable and why? > > > > On 01/06/2013, at 1: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> >>> <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> >>> <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 >>> >>> >>> >>>
