Jump to content
Search Community

updating vanilla object with browser specific css?

erikb 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

cleaned up some lingering questions at the end of a devolving thread [http://forums.greensock.com/topic/9639-unable-to-tween-via-proxy/] :-P

 

I've hit a snag using a vanilla object with css values and trying to apply those updated values to list of dom elements (with changing members).  For example, values like scale are not being changed to webkit-scale when in a webkit browser.

 

See the Pen Bikfy by jedierikb (@jedierikb) on CodePen


 

#1.

Is there a way to have greensock update a vanilla object with css values as it would update those values on a dom element?  Or should I use a dummy dom element (wherein dummy is defined as a dom element which I use to scrape the css values I need to apply to the current list members)?

 

#2.

What is the recommended way of getting a list of the keys and values greensock has most recently tweened on a vanilla object or dom element?  I want this information so I can apply these new values myself (via pure js) to dom elements in my list and not incur the performance penalties for .set described by Jack in the beginning of the post referenced above).

 

Link to comment
Share on other sites

Yeah, its the CSSPlugin that determines what vendor prefixes to attach. But the CSSPlugin only works on DOM elements as it needs to do some very DOM-element specific things like run getComputedStyle() to retrieve starting values of the tweened properties. Creating a generic object with a css property/object isn't the same thing.

 

So yes, I would guess that tweening a proxy DOM element would be a good route to tap into all the features of CSSPlugin. Some one else might have a better idea though.

 

#2

 

Not really sure there is an easy way for that other than you tracking them yourself. At any time you can query the vars of a tween

 

var t = TweenLite.to(element, 1, {opacity:0, scale:2, rotation:350, onComplete:function(){}})
console.log(t.vars)

But there could be many properties inside vars that aren't tweenable, like onComplete, repeat, yoyo, force3D etc.

 

Again this would give you properties of a tween, but the engine does not keep a list of "the most recently tweened properties" of an element (or object).

 

I regret that I don't have any better ideas at the moment.

  • Like 4
Link to comment
Share on other sites

Carl, Jamie: 

Thanks for the help.  I am now using a proxy element and via my .proxy style I am able to set display: none and still get all of the browser prefixes I need from that element (and keep that element off screen).

 

To get the list of css changes to the proxy element, I am using the CSSStyleDeclaration object [ https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleDeclaration ].

 

Here is my up to date codepen showing performance differences between greensock set and interrogating the proxy element's CSSStyleDeclaration and copying values over 'by hand':

See the Pen Dboca by jedierikb (@jedierikb) on CodePen

 

I am getting better performance when I do not use greensock set (but get all of the sweet greensock browser prefixes and transformation magic for my elements!).  I am pleased with the performance.  Since the codepen is using the most up to date version of the library, I guess the upgrade to 1.12 regarding thrashing issues did not benefit this issue very much?

Link to comment
Share on other sites

Thanks for the update and for sharing the demo. Pretty interesting test.

 

However, I really couldn't see a difference between toggling the useGreenSockSet variable.

I set it to both true and false. Perhaps I just don't know what to look for. 

 

One thing I would suggest trying is setting lazy:true. The performance article we released on 1.12.0 discusses how for set()s the default lazy is false but if you are doing a lot of set()s at once, you could benefit from lazy:true. The article notes that this could be helpful with lots of set()s in a loop (as long as code directly following the set relies on the set() happening firs), but I'm guessing it could apply to calling set() on a very large collection of targets as well.

 

 

So it might be worth chucking this in there:

 

if (useGreenSockSet) {
      TweenMax.set( tweenDots.buffer, {scale:proxyObj.scale, lazy:true} );
    }

 

I did try it, but like my previous tests could not easily decipher a variance in performance.

  • Like 2
Link to comment
Share on other sites

Thanks for the lazy:true suggestion.  I updated the codepen to include that change:

See the Pen pDnzC by jedierikb (@jedierikb) on CodePen

 

However, it did not result in a boost using my performance measurement technique.  I monitor FPS performance on chrome this way:

  • chrome : // flags
  • toggle the FPS setting

On my mac, using set yields a lowest framerate of about ~11fps. Using CSSStyleDeclaration yields a lowest framerate of about ~28fps (see framerate monitor at the top right of the images embedded below).

 

What is a better way to measure performance gains?  Is there a recommended plug and play module?  That would be superb (for this and other explorations).

 

 

 

set_false.png

set_true.png

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