Hi Thomas, I'm testing on FF. I thought it was probably just that I'm doing the impossible like you said too because the code I have for the animation is as concise as can be, the onUpdate() is just 2 lines of code which are just updating the top and left of the element. Maybe if I make the duration a function of the distance so that the achieved frame rate would stay below 60Hz it would work out nicely. But thanks again for the back info you supplied, very helpful, really appreciate it.
-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/-/y3cJB_TZzlYJ. 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.
