Jump to content
Search Community

Draggable div incredibly slow to react when using iOS

Tebbott test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hi,

 

I'm having real issues with a draggable map I've created, specifically on devices using iOS.  My animations all run nicely, however when I press and try to drag the map around, there's a good 4-5 seconds before the page responds, and then the move happens instantly, rather than smoothly.

 

If necessary I can provide you with a link to view the development site if that helps, however, I'll need to send it privately if possible? 

 

There are a number of layers creating the map, all stacked on top of each other - might this have something to do with it?  

 

Any help you're able to give me would be greatly appreciated.

 

Kind regards

Edited by Tebbott
Removed video link
Link to comment
Share on other sites

Hello @Tebbott and Welcome to the GreenSock Forum!

 

This type of thing is really hard to debug in a video, as well as trying to debug with your live development site, even if private. If you can create a reduced limited codepen example with just the GSAP code that is causing you issues and the elements they affect. This will allow us to debug your code in a live editable environment that we can see our changes in action. This will allow everyone in the community to help you to solve your issue faster.

 

 

Happy Tweening! :)

  • Like 2
Link to comment
Share on other sites

Hi Tebbott,

 

Sorry to hear you are having problems. The video definitely shows a problem, but as Jonathan said, a reduced test case is much better for us.

 

I have a strong suspicion that the complexity of your map (or something inside it) is to blame.

My suggestion is to replace your map with a single stagic image (png / jpg) as a test.

If performance increases than our suspicions are correct: Draggable is working fine and there is something in your map that is too processor intensive for your device. 

Link to comment
Share on other sites

Hi guys,

 

I appreciated your support. 

 

I was a bit stuck for time yesterday, and didnt fancy developing the whole map in codepen, however, I've just added the very basics i.e. just a background image with draggable enabled, and I immediately have issues with speed in ios.

 

You can see the pen here

 

See the Pen QaMyKd by tebbott (@tebbott) on CodePen

 

 

As you can see, it's a really simple set up - a 3000px wide map, that you can drag around within your viewport.  The live map has loads of vehicles moving around the map (all being transformed, rather than being move via left/right etc), so they will likely slow things down a little, however I dont understand why there's such a difference in response speed when you compare iOS to Android.

 

Again, really appreciate any assistance you're able to provide.

 

Kind regards

 

Andrew

Link to comment
Share on other sites

Hello @Tebbott Thank you for reducing your example so we can see it.

 

There will be differences between Android and iOS since both use different ports of webkit. So even though they both use webkit they have modified their own version of webkit to suit the needs of their different browsers (chrome and safari). That will mean that the CSS and JS can behave differently with various quirks and bugs.. or even different requirements to animate using transforms

 

You might want to look at making it so the cars only animate when inside the viewport. That will cut down on the constant frame rate of animating elements that are not even in the viewport to be seen.

 

So one way is to use vanilla JS and have a function that detects the viewport bounds like in this stackoverflow post

 

https://stackoverflow.com/a/7557433/1203457

 

Or you can try and use the Intersection Observer API to detect the viewport bounds

 

https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API

https://pawelgrzybek.com/the-intersection-observer-api-explained/

 

Then you can simply pause() and play() your animation depending if your elements are in the viewport.

 

Other than you might want to fork (copy) the codepen example you made and add a couple of the cars animating so we can see them animate in context to offer advice on how to optimize those tweens and or timelines.

 

Thanks :)

  • Like 3
Link to comment
Share on other sites

Hi Jonathan,

 

cheers for giving me a hand here.

 

Did you check out the Codepen example I provided, on an iOS device?   Even with the reduced test case, which contains no animations at all, the draggable map still takes around 2-3 seconds to respond to a touch event when you're using an iPhone or iPad.  

 

I really dont think it's a case that the animations are slowing things down - I mean, I might be wrong, but as the reduced example contains no animation and still isnt smooth on an iOS device, i'd assume the issue lies somewhere else.

 

I've just reduced the size of the map image I was using, by half, to see if it was the size of the image that was slowing things down, however it's still as unresponsive as it was before.

 

Pulling my hair out here. 

Link to comment
Share on other sites

@Tebbott 

 

Your SVG is like 4.64mb. That is a very huge asset to be pulling in the page via an <img> tag. You might have to mess with the SVG viewport attribute, to reduce the perceived size to the browser to render. But again that is a HUGE SVG that your pulling in the page with many assets inside that SVG. iOS has a very limited memory to render your asset based on the memory usage for iOS devices. Android probably has very different memory requirement than iOS.

 

It seems to be since your using an SVG instead of an actual image via the <img> tag. You should or could convert to an actual image, and you wont see that type of behavior in iOS, but still even a 4.64 image would do the same thing. Maybe slightly better but still, that is a lot of memory your asking  to render and load.  The 2-3 seconds to respond due to the high memory it takes to render the SVG when delivered in a <img> tag.

 

See the following which goes over the spec regarding memory usage for SVG and limits in iOS devices.

 

https://developer.apple.com/library/ios/documentation/AppleApplications/Reference/SafariWebContent/CreatingContentforSafarioniPhone/CreatingContentforSafarioniPhone.html

 

That limit is probably why even the SVG inside the <img> tag has that hesitation to load that huge SVG file, since it could be treated like a bitmap. But even if it isn't, that is way too big for memory usage in iOS.

 

:)

  • Like 4
Link to comment
Share on other sites

I see @OSUblake is about to respond so I'm sure he will have some great insight.

 

As Jonathan said, that SVG is insanely complex. I saw 1500 classes defined and what looked like hundreds of gradients and paths. I tried pasting the raw html source of the svg into CodePen and my browser locked up and the fans went nuts (i suspect CodePen was choking trying to apply the syntax highlighting).

 

I did a quick screen capture of the svg at around 1500 x 1500 and my busted up iPhone6 running iOS8 had no problem with the image of that size. 

 

Quick test using a png: https://s.codepen.io/GreenSock/debug/eyEWyw

 

This is definitely appears to be a case of a complex SVG sucking too many resources to render and update. I wish I had better news for you. 

  • Like 5
Link to comment
Share on other sites

Of course a 4.6MB SVG is too large!  I'm a @£$%ing idiot. 

 

Having said that, I've just switched the SVG out for a JPG that's 630kb, and the map is still slow to respond.  I've removed all animated elements from the mobile version of the site, so it's now simply a JPG background, with some links placed on top.

 

The strange thing is, moving your finger across the map leads to short, sharp burst of movement after 1-2 seconds, however, if you leave your finger pressed for 1-2 seconds, and then drag the map, the map starts to respond and you can move the map around smoothly.

 

I'll continue looking into this - I don't want to waste any more of your time - you've all been a real great help!

 

  • Like 1
Link to comment
Share on other sites

On 1/3/2018 at 10:32 AM, Carl said:

I see @OSUblake is about to respond so I'm sure he will have some great insight.

 

You and @Jonathan pretty much covered what I was going to post.

 

Basically that SVG is downright crazy!!! I've never seen such a complicated SVG before. Graphically it doesn't look complicated, but it took Illustrator and Inkscape around 10 minutes to load it. What's weird is that you can draw it immediately to a canvas element without any problems or delays.

 

On 1/3/2018 at 11:43 AM, Tebbott said:

Of course a 4.6MB SVG is too large!  I'm a @£$%ing idiot. 

 

Having said that, I've just switched the SVG out for a JPG that's 630kb, and the map is still slow to respond. 

 

630kb is the file size. The size in memory will be MUCH higher than that. If your image is 3000 x 2500, and each pixel is 4 bytes...

 

3000 * 2500 * 4 => 30,000,000 => 30MB

 

On a HiDPI display like a phone, your SVG would be even higher than that. If the device pixel ratio is 3, then the browser would be drawing your SVG at 9000 * 7500.

 

9000 * 7500 * 4 => 270,000,000 => 270MB!!!

 

And now your phone is out of vram!

 

You'll probably need to break your image up into smaller images, and only display what is visible with a little buffer around the edges. Pretty much the same thing that tile-based games do.

 

https://developer.mozilla.org/en-US/docs/Games/Techniques/Tilemaps

 

 

 

  • Like 6
Link to comment
Share on other sites

  • 3 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...