Jump to content
Search Community

play individual targets list

jonForum 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

hi, how i can play individual target initialised ? 

 

example here, i setup a tween list.
the var list contains a arrays list of target to initialize.

 

 

_huds_pinBar.prototype.setupTweens = function() {
    // pinGem scaling
    let list = [];
    this.pinners.forEach(slots => { list.push(slots.pinGem.scale) });
    this.tweens.pinGemScale = new TweenLite(list, 0, {
        x:0.4,
        y:1,
        ease:Elastic.easeOut.config(1.2, 0.2),
    });
};

_huds_pinBar.prototype.scalePinGem = function(x,y,duration) {
    if(duration){
        const t = this.tweens.pinGemScale;
        t.vars.x = x;
        t.vars.y = y;
        t._duration = duration;
        t.invalidate(); // TODO: deep study how this work
        t.play(0);
    }else{ this.scale.set(x,y) };
};

After If i play with scalePinGem, it play all instance?!
here what the scope give.
So did i need to initialise individual class for each obj , instead of assign a list?
but this will be a huge memory assignation.
0rJHxvwZ_o.png

9aOyLUH7_o.gif

 

Sorry if i explain myself bad in english, but you can see what a mean upper, i need scales individually each gem but with one instance of tweens.

Link to comment
Share on other sites

Hey jonForum,

 

Do you want to have all blue boxes opened at once or just one at a time?

 

I think if you just want one at a time, wouldn't it be better to asign a method that creates but doesn't return a single tween on over, rather than asigning all those tweens on all those elements?

Link to comment
Share on other sites

yes single box.
that what i thinking , so the correct way is maybe

replace this

 

    let list = [];
    this.pinners.forEach(slots => { list.push(slots.pinGem.scale) });
    this.tweens.pinGemScale = new TweenLite(list, 0, {
        x:0.4,
        y:1,
        ease:Elastic.easeOut.config(1.2, 0.2),
    });

 

to this =>

let i = 0;
this.pinners.forEach(slots => { 
        this.tweens[`pinGemScale${i++}`] = new TweenLite(slots.pinGem.scale, 0, {
            x:0.4,
            y:1,
            ease:Elastic.easeOut.config(1.2, 0.2),
        });
    });

 

is this the best performance ways?

Because create many `new TweenLite` seem heavy

Link to comment
Share on other sites

Not quite, you wouldn't create a Tween until you needed.

 

This is how I would go about it (have in mind I have no idea about your codebase, what you're using or how it is organized, this is just a suggestion)

 

this.pinners.forEach(slots => { 
  this.tweens[`pinGemScale${i++}`].scaleUp = this.scaleMeUp;
});


// Somewhere else
this.scaleMeUp() {
  const trg = this
  TweenLite(trg.scale, 0, {
    x:0.4,
    y:1,
    ease:Elastic.easeOut.config(1.2, 0.2),
  });
}

 

 

But even if you were to go with the code you have suggested, GSAP is super optmized, the vast majority of times you experience jank, it will be because of the rendering of the screen, not the tweening. And, unless you are tweening hundreds/thousands of objects, it's unlikely that you will see any significant difference in performance.

  • Like 3
Link to comment
Share on other sites

10 hours ago, Dipscom said:

But even if you were to go with the code you have suggested, GSAP is super optmized, the vast majority of times you experience jank, it will be because of the rendering of the screen, not the tweening. And, unless you are tweening hundreds/thousands of objects, it's unlikely that you will see any significant difference in performance.

threw a little worried after following a debugging step with the break.
if easing animation step i pass to ~~ 16ms to 23ms

I am not able to isolate the culprit but I suspect that it a call to a new constructor somewhere in tweenLite.

 

HM3pnFiI_o.png

 

the easing frame update lost me 7 ms , pretty huge for a simple easing feature.

Link to comment
Share on other sites

So you need to control each individual tween separately? They don't all animate at the same time to the same values? If that's the case, then you'd need a tween instance for each. Otherwise, just use a single tween and feed an array in as the target. And I don't see any reason to create all the tweens at once - you can just create them when you need them to run. 

 

Also, you can cache a single instance of Elastic.easeOut.config(1.2, 0.2) instead of calling that method again and again for each one. Config once, and reuse for all the tweens. 

 

invalidate() just erases any starting values that were recorded internally, forcing it to re-analyze/record the starting values on the next render. 

 

I'd strongly recommend against directly accessing any "_" prefixed properties like _duration because those are for internal use only. The proper way to set those is through the getter/setter, like tween.duration(newDuration). 

 

Like @Dipscom said, though, it's very unlikely that any performance problems are related to GSAP directly - it's typically something in the rendering pipeline that's the culprit. 

 

If you still need help, it'd be great if you could create a reduced test case in codepen that demonstrates the issue. It's just very difficult to troubleshoot blind (or just glance at an excerpt of the code). 

 

Happy tweening!

  • Like 1
Link to comment
Share on other sites

2 hours ago, GreenSock said:

So you need to control each individual tween separately? They don't all animate at the same time to the same values? If that's the case, then you'd need a tween instance for each. Otherwise, just use a single tween and feed an array in as the target. And I don't see any reason to create all the tweens at once - you can just create them when you need them to run. 

 

Also, you can cache a single instance of Elastic.easeOut.config(1.2, 0.2) instead of calling that method again and again for each one. Config once, and reuse for all the tweens. 

 

invalidate() just erases any starting values that were recorded internally, forcing it to re-analyze/record the starting values on the next render

 

I'd strongly recommend against directly accessing any "_" prefixed properties like _duration because those are for internal use only. The proper way to set those is through the getter/setter, like tween.duration(newDuration). 

 

Like @Dipscom said, though, it's very unlikely that any performance problems are related to GSAP directly - it's typically something in the rendering pipeline that's the culprit. 

 

If you still need help, it'd be great if you could create a reduced test case in codepen that demonstrates the issue. It's just very difficult to troubleshoot blind (or just glance at an excerpt of the code). 

 

Happy tweening!

hum, thank i will take on look on this.
I try made a codePen but i get error on load ressource ???

CodePen need special approach for load image ?
this is my test to build the app , am stock on load texture.

`We cannot complete this request, remote data could not be fetched`

See the Pen aRrZmN?editors=0010 by djmisterjon (@djmisterjon) on CodePen

 

It work on my playground test.

https://pixiplayground.com/#/edit/5GfBUnOWx5gkhcTi9PnTz
but on playground, i can not load external .js

thank

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