Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
andrewandopen

Tween glitching/staggering

Recommended Posts

Hey Guys,

 

Wondering if anyone can shed any light on this for some reason this particular animation keeps glitching/staggering when it enters a particular area (plane & clouds). All other parts seem to be working very smoothly, but this areas "skips" about half way through. wondering if you guys could shed any light on it?
 

 

Thanks!

Share this post


Link to post
Share on other sites

Hey Andrew.

 

You've got a lot going on there. But using the performance tools that dev tools has, it shows that the lag with the plane and clouds is due to compositing layers. In one of the raster threads it shows "image decode". Without seeing the code it's hard to say, but it looks like somewhere in your timeline you're decoding an image and that decoding is done every time the timeline is played through. 

 

In general it's good to make a minimal demo showing issues. Most the time you figure out what the issue is just by trying to create one :) 

https://greensock.com/forums/topic/9002-read-this-first-how-to-create-a-codepen-demo/

Share this post


Link to post
Share on other sites

Thanks for your reply Zach. I’m always happy to make a minimal demo if I can isolate the problem first, but with this I honestly can’t tell what’s causing the problem in the first place.

 

by “a lot going on”  do you mean I have too many animations working on the page as a whole??

Share this post


Link to post
Share on other sites
9 minutes ago, andrewandopen said:

by “a lot going on”  do you mean I have too many animations working on the page as a whole??

No, I just mean it makes it a lot tougher to find the issue :) 

Share this post


Link to post
Share on other sites

The following looks to be causing the majority of your page to 'repaint constantly' (Dev Tools > Rendering > Paint Flashing).

 

<div class="map-line triggerMap">
<svg preserveAspectRatio="none" width="1438" height="6297" viewBox="0 0 1438 6297" fill="none">
<path id="dotted-line" d="M1439.42 5C945.419 4.99991 7.41939 25.6474 7.41939 426.335C7.41939 935.137 1222.88 677.036 1295.06 1029.06C1367.24 1381.07 -22.6499 1238.31 5.41958 1666.33C33.4891 2094.36 1359.22 1773.09 1295.06 2157.11C1230.9 2541.13 436.925 2185.12 272.516 2621.14C108.107 3057.16 1467.49 2473.13 1415.36 3285.17C1387.29 3729.2 51.9671 2930.93 51.9671 3637.19C51.9671 4141.22 1003.69 4284.73 1211 4442C1559 4706 1275 4930 605.344 4909.26C-19.9763 4889.89 -7.02637 5582.5 212.366 5777.31C577.274 6101.32 966.242 6225.33 1423.38 6297.33" stroke="#EB592E" stroke-width="6" stroke-dasharray="24 32"></path>
</svg>
<svg preserveAspectRatio="none" width="1440" height="6299" viewBox="0 0 1440 6299" fill="none">
<path id="mask" d="M1439.42 5C945.419 4.99991 7.41939 25.6474 7.41939 426.335C7.41939 935.137 1222.88 677.036 1295.06 1029.06C1367.24 1381.07 -22.6499 1238.31 5.41958 1666.33C33.4891 2094.36 1359.22 1773.09 1295.06 2157.11C1230.9 2541.13 436.925 2185.12 272.516 2621.14C108.107 3057.16 1467.49 2473.13 1415.36 3285.17C1387.29 3729.2 51.9671 2930.93 51.9671 3637.19C51.9671 4141.22 1003.69 4284.73 1211 4442C1559 4706 1275 4930 605.344 4909.26C-19.9763 4889.89 -7.02637 5582.5 212.366 5777.31C577.274 6101.32 966.242 6225.33 1423.38 6297.33" stroke="#f9f7f3" stroke-width="12" style="stroke-dashoffset: -2451.88; stroke-dasharray: 13322px, 15783.9px;"></path>
</svg>
</div>

But having said that I am not really seeing any real obvious issues regarding what you call "glitching / staggering" on my machine?

 

I noticed that you are loading GSAP 3 but using GSAP 2 syntax. Since you are teaching courses I would advise agaisnt that and suggest using all GSAP 3 in your materials. Otherwise you will be providing a potentially confusing experience to your students.

  • Like 4

Share this post


Link to post
Share on other sites

I didn't have time to dig very deeply, but I noticed with the plane/clouds stuff you're using percentage-based top/left/bottom/right values which typically cause reflow, meaning it's tough on the browser. It's usually much better to use transforms like x/y instead of top/left. And percentage-based values force the browser to recalculate sizes too every time that percent changes. Have you tried ditching top/left/bottom/right for "x" and "y"? 

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, Shrug ¯\_(ツ)_/¯ said:

The following looks to be causing the majority of your page to 'repaint constantly' (Dev Tools > Rendering > Paint Flashing).

 

Repainting is necessary sometimes. For example, canvas/WebGL updates will always repaint.  So will SVG... in Chrome at least. It really depends on how complicated the repaint operation is. The more complicated the shapes, the slower.

 

I do see it get jumpy around here. I had to reduce the size of my screen.

 

image.thumb.png.4cd09f0fc93314761dad266f38e41dbe.png

 

 

But maybe the problem might be due to ScrollMagic. It hasn't been updated to work with gsap v3. Don't know why. It's a really simple fix.

 

 

  • Like 1

Share this post


Link to post
Share on other sites
6 minutes ago, GreenSock said:

I didn't have time to dig very deeply, but I noticed with the plane/clouds stuff you're using percentage-based top/left/bottom/right values which typically cause reflow, meaning it's tough on the browser.

 

Or it might not be scroll magic. I didn't look into your code, but this makes more sense.

  • Like 1

Share this post


Link to post
Share on other sites
10 hours ago, Shrug ¯\_(ツ)_/¯ said:

The following looks to be causing the majority of your page to 'repaint constantly' (Dev Tools > Rendering > Paint Flashing).

 


<div class="map-line triggerMap">
<svg preserveAspectRatio="none" width="1438" height="6297" viewBox="0 0 1438 6297" fill="none">
<path id="dotted-line" d="M1439.42 5C945.419 4.99991 7.41939 25.6474 7.41939 426.335C7.41939 935.137 1222.88 677.036 1295.06 1029.06C1367.24 1381.07 -22.6499 1238.31 5.41958 1666.33C33.4891 2094.36 1359.22 1773.09 1295.06 2157.11C1230.9 2541.13 436.925 2185.12 272.516 2621.14C108.107 3057.16 1467.49 2473.13 1415.36 3285.17C1387.29 3729.2 51.9671 2930.93 51.9671 3637.19C51.9671 4141.22 1003.69 4284.73 1211 4442C1559 4706 1275 4930 605.344 4909.26C-19.9763 4889.89 -7.02637 5582.5 212.366 5777.31C577.274 6101.32 966.242 6225.33 1423.38 6297.33" stroke="#EB592E" stroke-width="6" stroke-dasharray="24 32"></path>
</svg>
<svg preserveAspectRatio="none" width="1440" height="6299" viewBox="0 0 1440 6299" fill="none">
<path id="mask" d="M1439.42 5C945.419 4.99991 7.41939 25.6474 7.41939 426.335C7.41939 935.137 1222.88 677.036 1295.06 1029.06C1367.24 1381.07 -22.6499 1238.31 5.41958 1666.33C33.4891 2094.36 1359.22 1773.09 1295.06 2157.11C1230.9 2541.13 436.925 2185.12 272.516 2621.14C108.107 3057.16 1467.49 2473.13 1415.36 3285.17C1387.29 3729.2 51.9671 2930.93 51.9671 3637.19C51.9671 4141.22 1003.69 4284.73 1211 4442C1559 4706 1275 4930 605.344 4909.26C-19.9763 4889.89 -7.02637 5582.5 212.366 5777.31C577.274 6101.32 966.242 6225.33 1423.38 6297.33" stroke="#f9f7f3" stroke-width="12" style="stroke-dashoffset: -2451.88; stroke-dasharray: 13322px, 15783.9px;"></path>
</svg>
</div>

But having said that I am not really seeing any real obvious issues regarding what you call "glitching / staggering" on my machine?

 

I noticed that you are loading GSAP 3 but using GSAP 2 syntax. Since you are teaching courses I would advise agaisnt that and suggest using all GSAP 3 in your materials. Otherwise you will be providing a potentially confusing experience to your students.

So for your attached code  I'm using the GSAP drawsvgplugin to draw an SVG line, I'm not really sure why this would cause trouble?


The glitching/staggering is only visible in one particular part of the page (where the clouds and plane animate) , everything else is working fine. This is why I'm having so much trouble getting to the bottom of it. 
 

Share this post


Link to post
Share on other sites
9 hours ago, GreenSock said:

I didn't have time to dig very deeply, but I noticed with the plane/clouds stuff you're using percentage-based top/left/bottom/right values which typically cause reflow, meaning it's tough on the browser. It's usually much better to use transforms like x/y instead of top/left. And percentage-based values force the browser to recalculate sizes too every time that percent changes. Have you tried ditching top/left/bottom/right for "x" and "y"? 


Hey Jack, yes I tried different variations of "x" and "y" as opposed to top/left, it didn't seem to make any difference.

Share this post


Link to post
Share on other sites

There are HUUUUGE image decode tasks showing up in the performance audit. Your cloud image (https://tes-test-test--draft.superhi.com/cloud.png) is massive (7443px by 3206px). The plane is almost as bad - close to 5000x4000px. The browser is choking on decoding those and shrinking/rendering them. I'd strongly recommend using natively-sized images with 1-bit transparency to ease the load on the browser. A simple gif is probably best. 

  • Like 2

Share this post


Link to post
Share on other sites

👍 @GreenSock I also looked again today and was going to mention the huge image sizes being scaled down in css to 20%. That coupled with the previous suggestion about using more performant x/y etc., should go a long way to helping performance. ¯\_(ツ)_/¯ I should of taken more time to look before I posted initially, nice investigation Jack!

 

15 hours ago, OSUblake said:

Or it might not be scroll magic.

 

Say it ain't so. 😬 

  • Like 1

Share this post


Link to post
Share on other sites

Thank you all so much! It looks like you've solved it!

I'm relatively new to this coding stuff, so was always under the impression if my images are below 1MB everything should be OK.
 

16 hours ago, Shrug ¯\_(ツ)_/¯ said:

👍 @GreenSock I also looked again today and was going to mention the huge image sizes being scaled down in css to 20%.


@Shrug ¯\_(ツ)_/¯I certainly wasn't aware that scaling images would put more pressure on the browser. Again, I was under the impression the only thing that caused problems was the actual file size as opposed to the dimensions of the image.

 

12 hours ago, OSUblake said:

 

😲 That is using like 95MB of memory!

 


7443 * 3206 * 4 / 1000000 = 95.449032 MB

 

 

 

@OSUblake Would you mind explaining how you calculated this so I don't make the same mistake in the future?



@GreenSock @Shrug ¯\_(ツ)_/¯ @OSUblake Thank you so much! Only started using GSAP this week and am really overwhelmed by how responsive and helpful the community is! 

Share this post


Link to post
Share on other sites
4 hours ago, andrewandopen said:

I certainly wasn't aware that scaling images would put more pressure on the browser.

 

I wasn’t necessarily indicating that as a definitive issue. But when I was looking through your source code investing further it made me wonder why the 20% in the CSS and thats when I saw the huge images you were using. (As Jack pointed out before me).

 

4 hours ago, andrewandopen said:

explaining how you calculated this

 

I believe the formula is as follows:

width x height x 4 (rgba (channels)) / 1 megabyte (1000000 bytes) = mb of memory

 

@andrewandopen Are you a SuperHi user, if so I’m curious which course did this come from? Or are you actually developing the course which uses GSAP that will start on April 23rd ? https://www.superhi.com/courses/svg-and-css-animations

  • Like 1

Share this post


Link to post
Share on other sites
On 2/23/2020 at 7:11 AM, andrewandopen said:

@OSUblake Would you mind explaining how you calculated this so I don't make the same mistake in the future?

 

On 2/23/2020 at 11:25 AM, Shrug ¯\_(ツ)_/¯ said:

I believe the formula is as follows:

width x height x 4 (rgba (channels)) / 1 megabyte (1000000 bytes) = mb of memory

 

Shrug got it right.

 

On 2/23/2020 at 7:11 AM, andrewandopen said:

I'm relatively new to this coding stuff, so was always under the impression if my images are below 1MB everything should be OK.

 

A smaller file size means you can transfer stuff faster over the internet, but once it's loaded, the browser has to convert it to a bitmap, which will usually become much, Much larger. Image formats, like png, jpg, gif, and even svg, are just compressed/encoded image data, kind of like a zip file. The actual size in memory, the uncompressed/decoded size, is related to the actual dimensions of the image using that calculation above.

 

More about decoding an image in the browser.

https://dexecure.com/blog/image-decoding/

 

 

  • Like 2

Share this post


Link to post
Share on other sites

Thank you both @Shrug ¯\_(ツ)_/¯ @OSUblake

@Shrug ¯\_(ツ)_/¯ I am! I've done some of their courses in the past, however this project was not related to any of them. I use their editor sometimes as it gives you access to a live link (which is what I sent you). As I said, I've done some of their courses, but am not a teacher, nor do I work for them. 

 

Share this post


Link to post
Share on other sites

Well, thanks much dear friends! This is what I am looking for! :)

Share this post


Link to post
Share on other sites

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.

×