Actuate tween and Android

About Tween and Actuate and Android performance.
Trying to tween more than 4-5 (fade or grow or move has same results) make operations slow. Same results on virtual device and in reals.

Any suggestions to increase performance? Are there any known performance issue?

Thanks in advance.
David.

The tween itself should be inexpensive, what are you tweening? A DisplayObject x or y? Something else?

Thanks for reply and sorry for my delay but I’ve finally create a system help me to understood which operation drain power. First a little explanation.
Log you are going to see refer to a sequence of operations going from DisplayObject(s) creation to Tween passing from some others usefuls commands to create a Scene of my game.

---------------Map 556 Grouped----------------
Action Class: DisableInteractions overhead: 0.0370848178863525 times (14) ratio:0.0026489155633109
Action Class: FilterApplyingAction overhead: 0.000162124633789062 times (1) ratio:0.000162124633789062
Action Class: ActorCreationAction overhead: 1.00620007514954 times (37) ratio:0.0271945966256631
Action Class: FadeAction overhead: 2.07156600952148 times (25) ratio:0.0828626403808594
Action Class: AddPropertyToActorAction overhead: 0.00455999374389648 times (20) ratio:0.000227999687194824
Action Class: GenericWritingAction overhead: 0.104117155075073 times (5) ratio:0.0208234310150146
Action Class: AGCreationAction overhead: 0.759685039520264 times (15) ratio:0.0506456693013509
Action Class: SmallCardCreationAction overhead: 0.201578140258789 times (12) ratio:0.0167981783548991
Action Class: EnableInteractions overhead: 0.00531864166259766 times (27) ratio:0.000196986728244358
Action Class: GenericFunctionAction overhead: 0.000452995300292969 times (1) ratio:0.000452995300292969
Action Class: AvatarCardCreationAction overhead: 0.0409359931945801 times (1) ratio:0.0409359931945801
Action Class: MoveByAction overhead: 0.417968320846558 times (23) ratio:0.0181725356889808
Action Class: FilterRemovingAction overhead: 0.00106596946716309 times (1) ratio:0.00106596946716309
Action Class: MoveAction overhead: 1.3804669380188 times (70) ratio:0.0197209562574114
TotalCommands: 252 totalDuration: 5.8 totalOverheads: 6.03116221427917
---------------Map 556 End--------------------

I’m doing a series of 252 operations for a total duration (for duration I mean planned duration, for example if fade duration is 0.2sec but system user 0.32sec to achieve, duration is 0.2sec and overhead is 0.12sec) of 5.8sec. Full time eslapsed is 11.83sec.

Fade is the winner. This operation leak 2.07 sec in only 25 times of exection. Make some other use of same sequence I obtained varously results from 1 to 5 secs of overhead for this Fade operation. It’s a strange leak because it’s due in majority to these operations made to 6-7 DisplayObject simultaneously with this sequence for each:

847-cardInDeckInstanceName5| startingTime:1482963000.75245 endingTime:1482963000.7991 duration:0 @@@@@@ ActorCreationAction realDuration:0.0466480255126953
848-cardInDeckInstanceName5| startingTime:1482963000.79922 endingTime:1482963000.79998 duration:0 @@@@@@ FadeAction realDuration:0.000767946243286133
849-cardInDeckInstanceName5| startingTime:1482963000.80003 endingTime:1482963000.80047 duration:0 @@@@@@ MoveAction realDuration:0.000444173812866211
850-cardInDeckInstanceName5| startingTime:1482963000.80051 endingTime:1482963001.28409 duration:0.2 @@@@@@ FadeAction realDuration:0.4835770130157470

Last row of log highlight an overhead of 0.28sec for a single fade operation

Creation actions (ActorCreationAction, AGCreationAction, SmallCardCreationAction) are full overhead because they haven’t a planned duration and they use exptected time.

Move actions (Move and MoveBy) have a little and planned overhead.

Have some consideration about? I’m stressing tween too much? Any suggestion?
Thanks in advance.
David.

What does your fade action do?

public function redEvoFadeTo(value:Float, duration:Float = 1, easing:Dynamic = null, action:Dynamic) {	
	if(easing == null) {
		easing = Linear.easeNone;
	}
	Actuate.tween(this, duration, {alpha:value}).ease(easing).onComplete(action.declareEnd);
}

Called with parameters value=1, duration=0.2 easing=null. action.declareEnd has only work to signal the end of tween to log end time.

That’s all.
David.

Unless I’m misunderstanding, the time being tracked is related to the length of your duration, so 0.2 * 25 = 5 at a minimum, Actuate tweens based on a combination of Event.ENTER_FRAME and time elapsed, so the actual time it takes may be longer, since it synchronizes with frame events.

I don’t expect that the call is very expensive, but an alpha might be more expensive than others because of the autoVisible property, which toggles .visible to true or false at the beginning and end of the tween

To be honest the overhead is focused on 7-10 of 25 call (depends on parameter of the page called).
These 7-10 Fade calls are launched simultaneously on 7-10 different instances of same DisplayObject. I’m working to understand if this conjunction can be the cause of these concentration of overhead. Consider also that DisplayObject is quiet simple: a 30x30 sprite.

As highlight here I’ve obtained 0.28 overhead on a 0.2 duration fade for a 0.48 total duration as one of worse fade performance (please look at the end of the row)

850-cardInDeckInstanceName5| startingTime:1482963000.80051 endingTime:1482963001.28409 duration:0.2 @@@@@@ FadeAction realDuration:0.4835770130157470

Thanks again!
David.

Actuate uses frame times to do the actual updates, so at 30 FPS, the fastest tween will finish after at least 33ms, or for 60 FPS (if there is no drop in performance) it would be about 17ms, at least