The magnifying glass is harder (but with render to image you could do it I think). Otherwise I agree this should be quite doable.
Richard On May 31, 2013, at 9:17 AM, Scott Palmer <swpal...@gmail.com> wrote: > Flip the link from Mobile to Desktop at the top. > > I think JavaFX could easily handle this. > > Scott > > > On Fri, May 31, 2013 at 12:08 PM, Richard Bair <richard.b...@oracle.com> > wrote: > 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 > >>> > >>> > >>> > >>> > >
