Jump to content
Search Community

force3D as default

DannyT 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

As I understand it, force3D is not enabled by default because overuse can lead to severe performance issues?

 

If that's so, do we have any indication as to what is considered "overuse"? Is it animating x many items or so many pixels?

 

Just curious and appreciate it's subjective but if anyone has any more indication of when it's best to use and not to use force3D I'd be interested :)

Link to comment
Share on other sites

It's really an impossible question you're asking. It depends on so many highly variable factors (browser + version, device specifications, screen resolution, HTML structure, number of elements, element size, etc etc etc) that theres no way to possibly preempt at what point any site would be using "too much 3D".

 

The only sane answer is

  • pick a device and a browser
  • test it without force3D
  • add some force3D and see if it's better
  • add more force3D until everything you want is 3D, or performance worsens, or the browser crashes.
  • pick another device/another browser and start again
My only 'advice' would be to avoid it whenever it's not essential, especially for larger elements (and before you ask, I don't have a definition for 'larger' ;)). Sure, it sometimes makes things a bit smoother/prettier in a few browsers, but it always comes at the cost of memory and GPU cycles. If you count phones and tablets amongst your audience there's a plethora of low-memory devices out there you'll never have enough time to test with.
  • Like 3
Link to comment
Share on other sites

Hi,

 

Unfortunately I've never done any research in the "too many is too much" regard.

 

What you could try is fork this codepen from the GreenSock collection and play with it and see when the amount of elements becomes too much:

 

See the Pen srfxA?editors=001 by GreenSock (@GreenSock) on CodePen

 

Also this is more a empiric stuff (trial and error), like you said it'll depend on how many elements, the element complexity, the background behind the element and the viewport size, so it's very case sensitive. You'll have to see in every development what's the best alternative.

 

Rodrigo.

  • Like 2
Link to comment
Share on other sites

Hi,

 

Unfortunately I've never done any research in the "too many is too much" regard.

 

What you could try is fork this codepen from the GreenSock collection and play with it and see when the amount of elements becomes too much:

 

See the Pen srfxA?editors=001 by GreenSock (@GreenSock) on CodePen

 

Also this is more a empiric stuff (trial and error), like you said it'll depend on how many elements, the element complexity, the background behind the element and the viewport size, so it's very case sensitive. You'll have to see in every development what's the best alternative.

 

Rodrigo.

 

Good shout, a quick play already starts to give some indication.

 

I'm well aware it was a very subjective question but from a point of complete ignorance knowing whether 3, 30, 300 or 3000 animations is too much helps.

Link to comment
Share on other sites

I'd echo all the other sentiments already shared, and I'll also mention a few more things:

  1. Typically things perform better using force3D:true in terms of runtime performance during the actual animation, but keep in mind that there's a small trade-off in terms of the initial transfer of the texture to the compositor layer when it is created. So if you tried a test like this: http://cdpn.io/srfxA with a ton of dots, you'll notice that setting force3D:true would result in a noticeable delay initially before the dots start animating - that's the transfer from the browser to the compositor layer (making the texture for the GPU). That has nothing to do with GSAP, by the way - it happens for any element that has any 3D CSS applied. 
  2. In my experience, I've never run into a real-world project that performed WORSE with force3D:true. I have definitely seen many cases where it improved performance quite a bit. 
  3. It's probably best to avoid forcing a compositor layer on an element where you're animating the inner contents at the same time (like backgroundColor) because that will force the browser to have to recreate the texture to upload to the compositor/GPU, likely delivering worse performance. 

If you haven't already done so, you might want to read my article here: http://css-tricks.com/myth-busting-css-animations-vs-javascript/

  • Like 3
Link to comment
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.
×
×
  • Create New...