mrz

Hello, Ive got a timeline that animates the position of an element using left and Ive attached the onUpdate callback which triggers fine. My question is how can I check the current prop value at the point of the callback, e.g. if I am animating from left:100 to left:200 and the onUpdate() is triggered 10 times, I would like to be able to see 110, 120, etc.. I have done a search on the forums and come across a variable assigned to the element (_gsTransform) but it doesnt have the value I am looking for (left). I have quickly gone through the timeline object but couldnt find what I was looking for. I am currently working around the issue by calling getBoundingClientRect() on the element to get its current position. However I believe this causes a reflow and I want to avoid this, especially during an animation. I have made a codepen example that shows it working when I use x rather than left. But this issue remains with other props like top, left, alpha, etc

Hello again, Ive just tested it and it seems to be working well. Thanks for looking into both issues - will let you know if I find any more

Hi Diaco, Thanks - Ive put a workaround in for now. But the issue remains that the ticker might not sleep in some cases which causes the battery drain issues mentioned. Im sure its better to make the ticker/wake/sleep logic bulletproof rather than resort to workarounds - there should never be a case where the ticker doesnt sleep

Thanks for the tip, while trying to implement it I came across another bug for you If you play() a timeline until finish or set progress(1) and then play(), it will wake and never sleep.. So basically when a timeline has played until end and you try to play it again. Ive updated the codepen to demonstrate the above, the bug is in both 1.15.1 and 1.16.0 - http://codepen.io/anon/pen/OPEKgr Shame I didnt catch this before you released the new version! Are there any other scenarios where this might happen? I did run into one during testing but I was not able to replicate it.. it may or may not be the same bug.. but it seems there are very rare cases where the ticker continues to tick and ignore the sleep value of 30 or 120 or whatever it may be.

OK Ive just spent the past hour testing it on Android with the GPU profiler with the old/new GSAP and also against CSS transitions and Im very pleased with the results! It seems you must have fixed the issue where it would do a full 120 frames for every tween because now it stops using the GPU once the tween ends, no need for me to specify autoSleep or to even have oncomplete() handlers anymore! Ive taken some screenshots for you to see how much better it is now. Notice its also ~2x faster framerate and also uses less GPU time than CSS transitions! Now the only thing left is to get rid/reduce the tiny spikes at the beginning of each tween but I think this is probably unavoiable due to not having the ticker 'warmed up'. Anyway its not causing any noticeable issues so probably not even worth investigating. In the graphs below, each spike indicates the start of a tween/transition. The green line at the top indicates max time to hit 60fps, below that is what we want. All 3 run with transform3d so its an even playing field. 1) GSAP 1.15.1 (minified). There is only 1 peak because each tween would take 120 frames. This would waste battery as GPU was used for ~6x longer than needed. 2) GSAP 1.15.2 (uncompressed). 6 peaks = 6 tweens = 5x more tweens in the same time as the old GSAP. 3) CSS transitions (notice they take ~1.5x longer to render for the same duration/easing and also ~2x slower framerate). 4 peaks = 4 tweens. Very happy with the above Thanks for resolving it so quickly. I can now convert all the animations to use GSAP and will continue testing on other platforms/devices to see if the above performance improvement is consistent.

Thanks a lot! Thats fixed the issue, Ive tried to reproduce it and have not been able to. I have one question though, the autoSleep timer is definitely very helpful except in one scenario. If i use set the progress() on a timeline and pause it to jump to a specific point in the timeline, it will use the full # of frames I set before triggering GC. Is there any way for me to force GC to occur at points where I think it should happen? This would allow me to basically call them in between window transitions when I know there wont be a tween running and also allows me to be more flexible if the tween was longer/shorter than 30 frames or whatever. Ive tried calling TweenLite.ticker.sleep() and while this works initially, it just wakes up again straight after. edit: I say GC but I really just want to cancelAnimFrame because thats what triggers the GPU on android

Awesome, glad you could find it. For the second issue, do you think it would be feasible to have a flag where we could request GC to run at the end of tween, therefore saving the wasted cycles? It would be useful in the mobile scenario so after the 20-30 cycles once onComplete() is triggered, it would run the GC and cancelAnimFrame. Or maybe expose it via TweenLite.gc() or something and let us call it manually And if it was possible to set some sort of flag, e.g. TweenLite.iOS6Fix to allow us to avoid the 1.5 second rendering on page load. Most mobile users will be able to identify the target platform fairly accurately and it just seems to be a waste to have all platforms suffer at Apple's expense Thanks for your help! Let me know once there is a fix and Ill try and reproduce the issue again. Im not able to get it to reproduce in codepen for some reason edit managed to get it working in the codepen: http://codepen.io/anon/pen/gbKvXa sorry for the messy code - its quite possibly the worst example ever made

To be honest the entire range of mobile webviews are a joke.. so many inconsistencies and bugs but on the plus side it forces you to optimize as much as possible. You are right, pause is not necessary ive just tried it without. And it runs fine if you start from the beginning normally Anyway, Ive just gone through my steps and it seems I missed the final step! Sorry about that: 1) set up a paused timeline 2) add a tween 3) set progress somewhere in middle (doesnt have to be 0.5) 4) play the timeline 5) reverse the timeline! Everything is 100% fine up to step 5. Once you hit reverse it will start rendering 120 cycles indefinitely. Im trying to get this working in a codepen now, let me know if you have any luck edit: And its probably never come up before because I would assume most of the GSAP users would animate more than 120 cycles and probably dont mind having the renderer eating CPU/GPU in the background. For my purposes I only do animations that need 30 cycles or so and Im trying to optimize it as best i can.

It seems that anytime you call requestAnimFrame it hits the GPU (atleast on a mobile device). On chrome it presents itself as those 'ghost' paints/renders that have no source. I agree with the analogy of the sports car and having the ticker keep running and stay 'warm' and this is probably perfectly fine on a desktop pc. The thing is each 1 of those ticker cycles on a mobile is 0.01% battery life or whatever it may be. Like I mentioned earlier, I have been testing my app with several libraries and GSAP noticeably used battery by atleast 50% more during heavy testing. I would normally get a good day of testing on a single charge and when I swapped to GSAP it reduced to less than half - its obvious this was due to the 'wasted' cycles. Yep - latest Chrome version as mentioned above, running Windows 7 using the latest GSAP from the CDN. Tried the github version but no difference.. using the uncompressed one right now so I can mess with the source. I will create a codepen for you now, I think I can get it to reproduce reliably.

Sorry to triple post but Ive managed to narrow down the steps to reproducing the problem as well as found a workaround that resolves 1 of the 2 issues I raised initially. Steps to reproduce: 1) Create a timeline with paused:true and add a tween to the timeline, Im using a simple left:... tween set at 0.4 seconds long 2) Set an initial starting point for the timeline using: timeline.pause().progress(0.5); 3) timeline.play(); The expected result is that it will play until the end and stop because there is no repeat set. And you were right about repeat:0 it makes no difference if its set. The actual result is that it will play and finish BUT the rendering starts over again and this time it doesnt run the tween it simply repeats the timeline duration without animating forever and never calls sleep The workaround is nice and simple, you attach onComplete and onReverseComplete callbacks to the timeline and add timeline.pause() to both of them. Now the timeline only renders once and doesnt eat up GPU cycles afterwards. Now for the other issue.. If the tween is 120 cycles long but it visually 'finished' after 30 cycles of Animation._updateRoot, it still does the full cycle even if there is nothing left to tween which seems a bit wasteful. On top of that, it does the 14+103 cycles on page load which also seems wasteful. In short.. theres a bug where it doesnt stop rendering even after the tween is completed. Ive also exposed the requestAnimFrame id via a global variable and called cancelAnimFrame on it from the onComplete() handler and it would 'interrupt' the Animation._updateRoot at 29 cycles! and then finish the remainder 92 cycles So clearly the onComplete handler is being called at the correct time.. but for some reason rendering isnt stopped correctly. 26 cycles is great for mobile performance.. the other 92 wasted cycles not so much.. and the bug where it keeps rendering 119 cycles forever and ever just destroys the battery life. I hope I provided enough information to fix the issue..

Hello again, OK im making some progress. Ive looked at the source and added some logging and run a few tweens and noticed that you are right, it doesnt tween unless it has to. And then I started looking at the ticker code which seemed fine, it would wake, tween and then sleep a little while later which is fine. However.. in some cases, it has woken but not gone to sleep. requestAnimFrame continues to run in this time, generating all the 'traffic' in chrome timeline and this is what causes the ticking of the GPU on the mobile device. I havent yet identified what would lead to a wake but no sleep but I think Ill figure it out soon. edit: heres the log if it helps. you can see towards the end it wakes and runs 5000+ animation cycles (this continues to increment forever). there is no animation happening on screen and the tween had ended long before (show drawer and hide drawer are the tweens). also this shows you the 1-2 second of 'rendering' that occurs on page load.. there are 14 + 103 render cycles before I even interact with the page - just on loading the js...

Hello, Thanks for your reply - Ive definitely noticed that you guys place a huge priority on performance and thats exactly why Ive raised this issue. I had already watched your css performance screencast prior to posting this topic and Im aware the Chrome dev tools arent 100% accurate which is why I initially raised this issue on mobile only On Android devices you are able to profile GPU accurately and its a much better indicator of usage compared to dev tools. I have run more tests since yesterday and GSAP definitely causes the device to run hotter/use more battery because the GPU keeps running even after tweens have ended. Velocity stops animating much earlier than GSAP. CSS transitions are the most efficient when it came to time spent animating. Just INCLUDING TweenMax.js caused the page to render for approx 1-2 seconds on load and this is easy to reproduce as it doesnt invoke any code on my end. Regarding your point #2, it wasnt intermittent but I meant to say that the fix would only work for tweens going forward in the timeline. When playing in reverse repeat:0 didnt work. Adding stop() to the oncomplete and onreversecomplete handlers does work but as mentioned earlier there is an approx 1-2 second delay before it stops rendering. I think the easiest way for you to see what I mean is to simply include the TweenMax.js on an android webview and enable GPU profiling and reload the page and see the usage. I can provide a demo APK if it makes it easier for you (requires android 4.3+ for GPU profiling)? I will try and reproduce it using a normal website running on a mobile browser as well as that might be easier for you to test. I will take a look at the source and let you know what I find.

Hi there, The Android is a device, Galaxy Alpha running 4.4.4 Google Chrome is the latest Windows binary: 40.0.2214.115 m I no longer think this issue is specific to mobile/android as it is easily reproduced in Chrome using the example. Im aware of the left/x difference, I chose left because I did not require subpixel precision and the animation itself is already very smooth. I dont have a problem with the speed/fluidity of the tween. Its just that it continues to eat up render cycles even after a tween has completed. This isnt such a big deal on a desktop browser but it is critical on a mobile/laptop due to battery life. Ive just tested a similar example with Velocity.js and it doesnt have the same issue. Unless Im doing something stupidly wrong it seems GSAP keeps rendering even when not necessary (ie tween has completed). Ive reverted back to CSS transitions for now as its much more efficient GPU-cycle wise.

Hi guys, Firstly, thanks for a great product. It didnt take more than a few hours to start converting my animation code to use GSAP and get my head around the flash-based concepts. Im developing a webview application for Android and during testing (using the latest version of TweenMax.js from the CDN) Ive noticed that the battery drain was significantly higher than before I had started using GSAP. Now I know there could be other factors but after digging around using the GPU profiler on the Android device Ive noticed the following: 1) Just including the TweenLite or TweenMax JS includes causes approx 1 second of GPU usage on page load. This isnt the end of the world but it could significantly affect applications that reload the webview for whatever reason. This is before I even instantiate or run any tweens. 2) Setting up a simple TimeLine and adding a simple tween and playing it once using .play() the GPU will continue to tick even after the rendering is complete. This goes on indefinitely. A solution to this was to specify repeat:0 in the timeline options but im not sure why this isnt by default. This is probably the most serious bug as visually it would appear the render has completed but the GPU continues to burn battery life. In some cases when playing tweens in reverse, the repeat:0 fix above doesnt help. Ive found that adding .stop() to the oncomplete and onreversecomplete handlers has worked better. 3) If I specify an easing such as Expo.easeOut which seems to visually run faster than the duration Ive set, the GPU still continues to run even after the tween 'appears' to have completed. By this I mean once the tween has reached the target left/top property, it will still continue to run until the duration period ends. A simple check to see if the to target has been hit and abort rendering will stop this. Ive only been using GSAP for a day so I may be doing something wrong as the above issues make it rather unusable on a mobile device. Im only performing simple tweens for window transitions, etc.. nothing too strenous and using the very basic left/top options. Just quickly before hitting submit on this topic, Ive created a test in Chrome and viewed the timeline and its easily replicated on a browser. If you check the codepen, open timeline and start recording GPU events (rendering/painting) and click the box to start the tween you will see the events buffer keeps on filling up even after the tween has completed and even if the tab is running in the background. Now if you uncomment the lines code on lines #2 and #4, and do the same, you will see the events buffer stops a while after the tween finishes (around a second or so, roughly the same time as including the JS file causes). Is there something I have missed? Perhaps having the oncomplete handler call a timeline.stoprendering or something similar? I suspect its due to calling requestanimationframe even when there is nothing to tween? But I could be wrong, I havent looked at the code at all. I will try to replicate this behaviour with Velocity.js and report back.