Jump to content
Search Community

Performance when using both "webkitFilter" and "filter"?

mr.x 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

Has anyone noticed a performance hit when specifying both "webkitFilter" and "filter" in a tween? I figure there shouldn't be any difference, but my project animates smoothly in Chrome using "webkitFilter," but as soon as I add "filter" (for compatibility) it gets noticeably chunky.

 

I tried making a reduced-case sample in codepen, but the performance seems fine. So maybe I'm doing something else to cause the lag... 

 

i.e., 

// animates smoothly
TweenLite.to("#myDiv", 1, {webkitFilter:"brightness(0)"});

// animates chunky
TweenLite.to("#myDiv", 1, {webkitFilter:"brightness(0)", filter:"brightness(0)"});

Thanks in advance.

See the Pen ZeZZwm by xgraves (@xgraves) on CodePen

Link to comment
Share on other sites

Hello mr.x and welcome to the GreenSock Forum!

 

The webkit filter prefix is for older versions of Chrome 49 and below, and Android 4.4.4 and below. I didnt see the lag.

 

You could try and switch opacity to autoAlpha for a slight performance boost.. See the CSSPlugin autoApha property:

 

autoAlpha

 

https://greensock.com/docs/#/HTML5/GSAP/Plugins/CSSPlugin/

  • Identical to opacity except that when the value hits 0 the visibility property will be set to "hidden" in order to improve browser rendering performance and prevent clicks/interactivity on the target. When the value is anything other than 0, visibility will be set to "inherit". It is not set to "visible" in order to honor inheritance (imagine the parent element is hidden - setting the child to visible explicitly would cause it to appear when that's probably not what was intended). And for convenience, if the element's visibility is initially set to "hidden" and opacity is 1, it will assume opacity should also start at 0. This makes it simple to start things out on your page as invisible (set your css visibility:hidden) and then fade them in whenever you want.
//fade out and set visibility:hidden
TweenLite.to(element, 2, {autoAlpha:0});

//in 2 seconds, fade back in with visibility:visible
TweenLite.to(element, 2, {autoAlpha:1, delay:2});

You could also make sure that your image is fully loaded before animating it which could cause some lag. And adding a slight rotation:0.01 to your tweens so they use matrix3d() instead of translate3d(), and see if that helps.

 

But i could not see any lag. tested in latest Firefox and latest Chrome on Windows 10. :)

  • Like 2
Link to comment
Share on other sites

Thanks Jonathan! I appreciate you looking into this and replying.

 

I couldn't reproduce the problem in that codepen either, unfortunately. There's still lag in my actual project though, so I'll play around with that pen and see if I can replicate it. I'm guessing the browser has to be taxed, or maybe I crossed some wires with a lot of Timeline tweens.

 

In any event, I wanted to check with you guys in case it was a known quirk. It almost seemed like Chrome was applying both filters instead of choosing one, but it's more likely a render issue or something. I'll do some more tests and report back if I find anything interesting. 

 

Oh yeah! I totally forgot about "AutoAlpha". Back in my AS3 days I used it all the time. I'm going to bring it back, thanks for the reminder! B)

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...