[FIXED] Transitions jerky

Solar2D Advanced Graphics
#1

My transitions inside groups that are in motion (dragged around) are not smooth anymore. They are quite jerky while pre g2 it is all smooth. Only tested in simulator so far. The graphics are not intensive or anything and it has always been silky smooth, even on low end devices.

I also notice alpha transition that are dragged off screen and should still complete normally are not completing fully.

I’m using latest build, 2085.

Are there more transition fixes coming? I’m just hoping I do not need to make a demo of this. Spent so much time on G2 reporting.

#2

Same thing here with jerky animations (with newSprite) that were ok pre-g2. Also using 2085.

#3

Thanks for that claudeturcot. Come to think of it I’m using newSprite in these transitions as well.

#4

Are you fading in the images? There’s been some discussion over the last few days of juddering caused by images being loaded, set to alpha of 0 and fading in. The cause in that case was that images currently aren’t loaded upon calling newImage(), but when they are first drawn, causing the hit as they load from the alpha transition. This will be changed in an update soon.

If not, got any more details?

#5

@rakoonic: I am fading from alpha 0 before the transition but I saw that post so I tested not having the fade and it made no difference.

That build with the fix is up btw. It did not change anything for me. I’ll probably end up making a test case if I don’t see any changes in the builds before the weekend. 

#6

OK good plan, sorry I couldn’t be of more use.

#7

No, not playing with alpha on my side. 

To be clearer, what I have is a walking man animation that when the transition finish I switch to an idle animation. Both are pre-loaded. 

Before the transition between the 2 animation were seamless. Now when the walking is finished, it stop at the last frame for a second then the other start… it’s clearly perceptible and doesn’t look good.

#8

I managed to nail down the bug for my problem. 

Basically after transitioning a child Y position, then transitioning the anchored parent X position, the childs Y position is affected. This was not the case pre-graphics 2.

Its easier just to see in this sample.

[lua]

– Copy paste into main.lua

local group          = display.newGroup()

group.anchorChildren = true – Commenting this out and nothing will jump around

group.x              = 150

group.y              = 200

local box = display.newRect(0, 0, 90, 54)

box:setFillColor(1,0,0)

group:insert(box)

transition.to(box, {time = 1000, y = box.height})

–box.y = box.height – Comment this in + transition above out, nothing will jump around 

– This transition will affect the y position of the red box, but should not

transition.to(group, {time = 1000, x = 50, delay = 1200})

[/lua]

Reported bug, case 28332.

#9

Your post title talks about jerky movement but the last sample you posted shows a bug in the transition code where it’s using the box.y value at the time the transition was setup. Are you still seeing jerky transition too (compared to g1.0)? Your bug report only mentioned the box.y positioning issue.

#10

My actual app shows this behavior when I drag a group (slideview) and thus the transitions appeared to be jerking around on the drag, hence the title of the post. The real problem is what I reported.

#11

We resolved the bug that was the result of setting “anchorChildren = true” on a group with only one child. Here is what I replied in the bug report.

The bug has been fixed but it’s not the bug you reported. The bug was the rect moving down in the Y direction during the first transition. The transition shouldn’t move the object at all because anchorChildren was set to true and there was only one child in the group. Your first transition was trying to move the child and not the group.

When you set “anchorChildren = true”, you are settings the group bounds to that of it’s children. Since you only have one child in the group, it’s bounds becomes the bounds of the group. Your first transition attempts to move the child within the bounded group. Since the group bounds and the child bounds are the same, there is no movement. If you had multiple children or did a transition on the group itself, you may see movement (depending on the direction).

When you set “anchorChildren = false” (default condition), the group is not bound by the children (has an infinite boundary) and doing a transition of the child, moves the child in the group.

Setting “anchorChildren = true” on groups is not a good idea unless you have a specific need for using anchor points on groups.

#12

Thanks for the update. 

My understanding that groups prior to G2 where anchoring children. I seem to be misunderstanding that? 

My main method is to position stuff inside the group, then I move the group to where I want it. So I construct something like a footer at 0,0 and then move the final footer group to the bottom. So when porting my project to G2 I put anchorChildren in multiple places. 

#13

Regarding this point in original post:

I also notice alpha transition that are dragged off screen and should still complete normally are not completing fully.

I got around to tracking it down. When groups are going off screen in mid transition, and then come back onscreen, the transition never finished. Try this code:

[lua]local group = display.newGroup()

local box = display.newRect(50,50,100,100)

group.alpha = 0

group:insert(box)

– Transition the group to full alpha in 800 ms

transition.to(group, {alpha = 1, time = 800})

– Transition group offscreen where  above transition will not finish

– Oncomplete, bring it back, it will not be 100% white since 

– alpha transition above did not finish.

transition.to(group, {x = -200, time = 900, onComplete = function() group.x = 0; end})

[/lua]

I reported case 28784.

#14

Same thing here with jerky animations (with newSprite) that were ok pre-g2. Also using 2085.

#15

Thanks for that claudeturcot. Come to think of it I’m using newSprite in these transitions as well.

#16

Are you fading in the images? There’s been some discussion over the last few days of juddering caused by images being loaded, set to alpha of 0 and fading in. The cause in that case was that images currently aren’t loaded upon calling newImage(), but when they are first drawn, causing the hit as they load from the alpha transition. This will be changed in an update soon.

If not, got any more details?

#17

@rakoonic: I am fading from alpha 0 before the transition but I saw that post so I tested not having the fade and it made no difference.

That build with the fix is up btw. It did not change anything for me. I’ll probably end up making a test case if I don’t see any changes in the builds before the weekend. 

#18

OK good plan, sorry I couldn’t be of more use.

#19

No, not playing with alpha on my side. 

To be clearer, what I have is a walking man animation that when the transition finish I switch to an idle animation. Both are pre-loaded. 

Before the transition between the 2 animation were seamless. Now when the walking is finished, it stop at the last frame for a second then the other start… it’s clearly perceptible and doesn’t look good.

#20

I managed to nail down the bug for my problem. 

Basically after transitioning a child Y position, then transitioning the anchored parent X position, the childs Y position is affected. This was not the case pre-graphics 2.

Its easier just to see in this sample.

[lua]

– Copy paste into main.lua

local group          = display.newGroup()

group.anchorChildren = true – Commenting this out and nothing will jump around

group.x              = 150

group.y              = 200

local box = display.newRect(0, 0, 90, 54)

box:setFillColor(1,0,0)

group:insert(box)

transition.to(box, {time = 1000, y = box.height})

–box.y = box.height – Comment this in + transition above out, nothing will jump around 

– This transition will affect the y position of the red box, but should not

transition.to(group, {time = 1000, x = 50, delay = 1200})

[/lua]

Reported bug, case 28332.