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