Hi Thomas, Actually, just had one last question. I went actually tested to make sure. I'm running my animation 1000ms like above and kept track of the number of times the onUpdate() function is being called. I'm getting an average of 12 calls/updates, this would mean that I'm achieving 12fps? Does that mean there's a problem? Thanks again.
-Seth On Tuesday, April 17, 2012 12:07:36 PM UTC-4, Thomas Broyer wrote: > > > > On Tuesday, April 17, 2012 6:05:19 PM UTC+2, Thomas Broyer wrote: >> >> >> >> On Tuesday, April 17, 2012 5:43:03 PM UTC+2, GWTter wrote: >>> >>> Hi all, >>> >>> I've written a move animation using the gwt way (extending animation >>> class etc.) and it works great but I've noticed that when that if I keep >>> the duration the same say 1000ms the longer the move distance is the >>> choppier the animation seems (the animation is smoother the shorter the >>> move distance is). I figured that this is because of the frame rate. In the >>> doc the frame rate is stated to be "non-fixed". >>> >>> Does anyone know if it is possible to increase the frame rate on the >>> animation >> >> >> No, it's not possible. >> >> >>> and if not can anyone suggest or have an idea on how to make the >>> animation smoother? >>> >> >> Which browser were you testing this in? In Firefox and Chrome it should >> use requestAnimationFrame whose role is to defer to the browser the choice >> of the frame rate so that it stays responsive >> See https://developer.mozilla.org/en/DOM/window.requestAnimationFrame >> and >> http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/animation/Animation.gwt.xml >> (and >> http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/animation/client/AnimationSchedulerImplTimer.java >> which >> uses a timer that tries to achieve 60Hz frame rate) >> >> If your animation is not smooth, it's probably that it doesn't run at >> approx. 60Hz, which means that either your code in the animation or some >> other code runs too slowly to achieve that rate. Because timers and >> requestAnimationFrame (and basically everything in a browser) go through >> the event loop and task queues < >> http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loops> >> >> it can be that something else than the animation is pushing too many tasks >> in the queue and/or that those task run slowly, delaying other tasks and >> therefore prevent reaching the 60Hz target rate. >> >> Oh, of course, it can also be that you're trying to do the impossible, > and the only solution would be to run the animation for a longer duration > so that the moves between each frame (at the same frame rate) are smaller. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/sAsfTo2dYoYJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
