Draggable - CPU never released on IOS platforms

[ugo]

Hey. We've been working on trying to find the source of that issue but basically, whenever we try to instantiate the draggable instance with whatever Draggable(element, ops) or Draggable.create(element, ops), each time we are calling the draggable instantiation on IOS and then we try to umount the component it seems like the CPU usage is still the same and got never release from the instances call. We tried to call the kill method to destroy the instance to clear the CPU on the unmount hook of the component but this doesnt seem to work either. You can try checking my codepen from a IOS device and in the safari inspector, click on the Timeline tab and check the CPU usage. You'll notice that also on the first load ( without yet starting to interacting with the element ) the CPU usage is already very high (up to ~ 30% reproducible on Iphone XS IOS 14 ~ 16 the latest ). On Android as on web this seems to be fine tho. Let me know if you need more information or if you have any idea of how we could solve that, thx !

See the Pen DgqxVe by jamiejefferson (@jamiejefferson) on CodePen

[Rodrigo]

Hi,

 

What particular framework are you using? Vue, React, Svelte, other? You mention an unmount hook so my suggestion would be to use GSAP Context for this:

 

https://greensock.com/docs/v3/GSAP/gsap.context()

 

You can also read more about how is implemented in React here:

 

Here are some starter templates that show how is implemented:

• Vue3  https://stackblitz.com/edit/vue-dm3aa9
• React https://stackblitz.com/edit/gsap-react-basic-f48716
• Svelte https://stackblitz.com/edit/vitejs-vite-zegpxi

You can fork any of those to create a minimal demo that clearly shows the issue you're having. The one you linked created by Jamie is almost 8 years old and is using GSAP 1.18. We're currently on 3.11.5 so a lot of code has passed under the bridge in these years

 

Happy Tweening!

[ugo]

Hey, sorry we didnt notice that the codepen was set with GSAP 1, please find attached below the updated codepen using GSAP v3  

See the Pen jOeNrBm by darondel-yoobic (@darondel-yoobic) on CodePen

. Thanks for your recommandation about using the gsap.context method. We had been able to update our codebase to be working alongside the gsap.context but unfortunately this didnt fix our issue. When setting up the pattern we made sure that whenever the revert method from gsap context was called that all draggable instances was cleared, that was the case, however we still get a high CPU usage after calling the revert from the context.

 

As for the previous codepen, you can simulate the issue by checking the codepen from an IOS device and then using the safari inspector, just go to Timeline > CPU and record ( red square on the top left corner ), you will notice that the CPU usage is already high on the first load of the component ( without any interaction with the element). And then just click the "close sprite" button below to simulate the revert and observe the CPU usage, you will notice that the CPU usage is still high pretty much like nothing had been discharged by the CPU after the revert, even though we checked that the draggable instance was destroyed on the post revert.

 

Also, please find attached below 3 screenshot:

1. A screenshot from the video record of the CPU usage while loading the codepen from a safari on IOS

2. A screenshot from the video record of the CPU usage while loading the codepen from a safari on Web 

3. A screenshot of the js/event logs processed after a revert from the context ( where the supposed the draggable instance should be cleared ).

 

So as you can see, this might have an issue with discharging the CPU from IOS ( whereas this is working fine on Web, Android and Chrome ).

We've tried to kill draggable instance manually and via the context and this lead to the same result.

Any more idea to help us out ? or would you consider this to be an issue on your side ? 

Many thanks.

 

 

[GreenSock]

I think you may be worrying about something very insignificant. Draggable has a render queue that's optimized for speed and it leaves a requestAnimationFrame() active for up to 15 seconds after the last interaction so that it doesn't have to keep adding/removing ticker listeners on each interaction. But after about 15 seconds if there haven't been any interactions, it powers down and removes the listeners from the ticker.

 

The actual work that's necessary on each tick is minuscule, as you can see in the event log. There may be an issue in the way Safari's Dev Tools reports things, as whenever you have the Dev Tools open it has to do a bunch of extra work to track everything, thus I'd imagine there's more demand on the CPU. In practical reality, though, I cannot imagine a simple requestAnimationFrame() would cause any noticeable difference whatsoever.