Jump to content
Search Community

Tweening when there's nothing to tween... Is this cheating?

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

OK, I've wondered about this for the longest time and have decided to ask for your opinions...

 

I find myself building a lot of user interface stuff (menus, etc) and I'm always at odds of how to handle this. For a super basic example, consider this:

 

Suppose I have five menu items and I want to have the the active one at full opacity and the other four at half opacity. So when a menu item is clicked, it goes to full opacity and the one that was at full opacity fades to half opacity. Simple, right?

 

In jQuery, I can assign an "activeButton" class to the one that has been clicked and then use that as the selector to fade it when another is clicked... and then of course un-assign that class to the old button and assign it to the new active button.

 

OR (and here is where I think this may be cheating) I can tell ALL of the other buttons to fade, even though only one of them really needs to fade and be on my way! I've done it both ways and never noticed any difference or performance hit from tweening all of them... but I'm not sure if there are other ramifications. I used to do the same thing in AS at times, but honestly with jQuery, using not() makes it too easy:

 

$('.menuButtons').not('#thisButton')

 

Thoughts? If something is being asked to tween to X even though its already at X, does it take up much in the way of resources? So should I be losing sleep over this? I find myself "cheating" when I'm in a time crunch, but maybe there's no problem with it?

Link to comment
Share on other sites

Good question.

 

I don't think you would ever notice a performance hit if you were tweening 5 or 50 x values to 500 if those x values were already at 500.

 

As your apps get more complex and there are more challenging screen updates happening it would be advisable to always consider being as efficient as possible.

 

using jQuery to assign and toggle an "active" class sounds like a fine way of making sure that only the necessary object(s) are being tweened. From my actionscript background I'm more accustomed to store a reference to the active button like so:

 

var activeButton;
//assign all the buttons the same click function
$('.button').click(function (e){

  //check that there is an activeButton and that it isn't the one you are clicking	  
  if(activeButton && activeButton != this){
//reset the activeButton to its normal state  
TweenLite.to(activeButton, .2, {css:{backgroundColor:'#c00'}});
}

//tween the clicked button to its active state
TweenLite.to(this, .5,{css:{backgroundColor:'#0066cc'}});
//update the reference to activeButton to be the button that was just clicked
activeButton = this;		

})​;​

 

see it in action here: http://jsfiddle.net/...bassador/FE8M7/

 

 

-c

  • Like 1
Link to comment
Share on other sites

Thanks, Carl... I would agree with everything you said and appreciate your as sample. Coming from an as background as well, really miss it sometimes now that most of my projects are jQuery (thanks, Steve) although I am still picking up some Flash gigs here and there. :-P

 

I would also agree about sorting through larger objects. I definitely keep track of them by assigning an active class so that I'm not tweening anything more than I have to.

 

Thinking about the example I gave with the buttons, I really should have thought that through more. I think most of the time I am inclined to tween objects that are already tweened, is when a user experience allows multiple bits of interaction, and I need to quickly be able to set everything back to square one. So if there are a few objects that have been clicked causing them to move, or change color, etc... I may just call a function to reset everything. Which may mean that some items in a class are changing back, while others may have never been changed to begin with. In this situation, I can achieve ALL of this with a simple TweenMax.allTo and POOF! Again, my not be the most efficiant use of resources, but there's something to be said for keeping the code to a minimum.

 

Guess I'll continue on a case by case basis... but glad to hear your thoughts as well. Don't feel so guilty now! :-)

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