transition.cancel() weirdness after build 2014.2365

I’m not sure if anybody else is seeing issues, but the fixes that were introduced in build 2014.2365 that allegedly fixed problems with transition.cancel() is wreaking all sorts of havoc with my code.

All builds up to and including 2014.2363 work just fine.

transition.cancel() just doesn’t work the same way it used to, and the results of my testing makes no sense which makes it so much more difficult to write a bug report.

I’ve already reported three regression issues regarding transitions after the “fixes” of 2365.

Two were fixed in build 2014.2370, the other is pending, but there are more which make it impossible for me to use anything newer than 2014.2363 at the moment…

Not a happy camper…  :angry:

I know you posted the bug # the other day, can I get it hear as a reference?

Thanks

Rob

Seriously?  Ingemar, if you have time, I’d be so grateful if you can describe what kind of weirdness you are seeing.

I submitted my latest app to Apple with 2014.2370 the night before, and I haven’t seen the issues I saw in 2014.2368 – but it could be that my testing is yet to hit a case that would cause the havoc you are seeing with transition.cancel().  If it is applicable to my app, I’d need to developer-reject the submission and resubmit with 2014.2354 (with which I tested my app most extensively so far.)

Naomi

The outstanding one is Case 34162.

(The fixed ones in build 2370 were 34032 and 34033)

However I think I’ve stumbled upon several more issues. It’s difficult to track what’s going on as the behavior is morphing depending on the statements I use. I’m also *sometimes* having issues with the Composer API that I haven’t seen before when changing scenes. Putting a gotoScene within a timer.performWithDelay(10,…) seems to bring back the original behavior, but I can’t understand why timing all of a sudden has become an issue. The problem here again is that it’s only certain scenes, and not all.

There also still seem to be issues with the transition API when using objects and tag-names in certain circumstances.

It’s all a bit frustrating, but I’m trying to track down these issues as fast as I can, because I don’t want to get stuck on build 2363.

@naomi

The problems I’m seeing are apparent when using the app, so as long as your testing doesn’t show any problems I think you’re OK. Honestly I have yet to find out what the actual problems are. Some of my composer scenes are OK, some are not.

Like I’ve said above: Life was good up to build 2363. It’s very late here now and I need to get some sleep. I’m going to tackle this in the morning.

Thank you, Ingemar.  It’s reassuring.

A new bug I found (or it could’ve been there for a while but I didn’t see it until a couple days ago) was with starting a transition after transition.cancel was called.  So I added a timer delay for the transition that needs to start immediately after transition.cancel, which fixed it for me.  Otherwise, I haven’t seen any issues so far.  

Composer scene changes have been working as expected for me.  

I’ll test some more today without developer-rejecting my submission.

Thanks again.

Naomi

A new bug I found (or it could’ve been there for a while but I didn’t see it until a couple days ago) was with starting a transition after transition.cancel was called.  So I added a timer delay for the transition that needs to start immediately after transition.cancel, which fixed it for me.

That behavior started with build 2365 and is consistent with my testing. I think it’s related to the issue I have where I have to put a gotoScene in a timer.performWithDelay() for my transitions to work in the new scene.

(I’m going to publish my findings on this thread as they become available)

Issue 1:

I’ve found that the fix for 34033 doesn’t fully fix the tagname re-use issue. This is similar to the outstanding bug report I have reported above (34162).

I have several scenes with background elements that are the same. The elements have the same tagname in all scenes. I use transition.cancel(tagname) in the “will hide” event from one scene and a transition.to(…tag=tagname) in the “will show” event in the next scene. What happens is that the animations fail to start in the new scene.

There are 2 workarounds for this issue:

  1. Use a separate tag-name in the second scene

  2. In the second scene, issue the transition.to() call within a timer.performWithDelay(). The delay must be at least 2 to work.

Thank you, Ingemar, for the details.

It sounds like the timer.performWithDelay() that I used to fix my problem probably solved other potential problems that could’ve given me headache with the 2014.2370 build.  Thank goodness, it sounds like I can let it stay for now.  Whew, a sigh of relief.  (Releasing a build is never ever smooth, is it?)

Thanks again.  I really appreciate your thorough approach to testing & investigating issues.

Naomi

P.S.  BTW, for good measure, I gave it 100 for the timer.performWithDelay() when I implemented my workaround.   :wink:

@Naomi

Yeah, better to be safe, 100 ms isn’t noticeable in many cases anyway.

ingemar,

Just letting you know that i’m looking into the remaining issues you found.

Thanks,

alex

@alexandru

Thanks, much appreciated !

Issue 2:

There seems to be some “cancellation memory” going on as well.

I’ve noticed when I issue a transition.cancel(object) that the next time I call transition.to() for that same object the cancel event is immediately fired. However if I (for example) cancel the transitions for 6 objects, only the last object will get the cancel event called when a new transition is put on it.

I tested this by adding an onCancel event for all my transitions to see what was going on. 

This one is tricky, and I haven’t nailed it down perfectly yet, however I’ve had success with a potential workaround.

I’ll need to do some more testing to completely understand what’s going on before I can tackle creating a bug report… 

Potential Workaround:

Assign the transition handle to a property and do the cancel on the property. i.e.

-- this can sometimes cause issues function object:reset() transition.cancel(self) end . self:reset() . transition.to(self, ...) . . some code . self:reset() . . some code (can take several seconds to execute) . transition.to(self, ...) -- will not start the new transition on the object -- workaround function object:reset() if (self.transHandle) then transition.cancel(self.transHandle) end end . self:reset() . self.transHandle = transition.to(self, ...) . . some code . self:reset() . . some code (several seconds) . transition.to(self, ...) -- will start the transition

Good news.

It looks like all of the weirdness I’ve been seeing has been narrowed down to a combination of the issues I’ve reported above.

I was able to get my troublesome project running with build 2373 with the workarounds I mentioned. I still need to create a bug report for the last issue I mentioned above, hopefully I’ll be able to recreate it in a simple project.

Phew… first time it’s taken me this long to figure things out. (where did the weekend go  :wacko:???)

I filed a bug report (Case 34276) for the issue with transition.cancel() acting strangely when you supply the variable for a display object as the argument. I didn’t discover this thread until afterwards, so it would seem that the problem is larger in scope than I originally thought. Anyways, here’s the description I gave in my bug report:

Starting with daily build # 2014.2365, calling transition.cancel() with a display object as the sole argument results in unwanted behavior. The transition successfully cancels, but future attempts to perform a transition to that display object are unsuccessful, with no error outputted to the terminal. I have confirmed that this bug first presented itself in daily build # 2014.2365, up to and including the most recent daily build as of today (#2014.2373). Using transition.cancel() while supplying a handle or tag instead of a display object as the argument works as expected in my testing - this issue seems to be isolated to cases where you supply the a display object’s variable as the argument.

See the attached main.lua, which has buttons to perform the following:

1.) start a transition on the rectangle in the center of the screen

2.) cancel that transition, supplying the rectangle’s variable as the sole argument to transition.cancel()

3.) re-start the transition.

4.) repeat steps 2 & 3 as often as you want.

Using daily build # 2014.2365 or earlier, this little program works as you’d expect. But starting with build # 2014.2365, step 3 above does not work.

And here is the main.lua file I supplied as a test case:

------------------------------------------------------------------------------------ -- REQUIRE WIDGET LIBRARY ------------------------------------------------------------------------------------ local widget = require("widget") ------------------------------------------------------------------------------------ -- DELARE POSITIONING VARIABLES ------------------------------------------------------------------------------------ local centerX = display.contentCenterX local centerY = display.contentCenterY local screenTop = display.screenOriginY local screenLeft = display.screenOriginX local screenBottom = display.screenOriginY+(display.contentHeight-(display.screenOriginY\*2)) local screenRight = display.screenOriginX+(display.contentWidth-(display.screenOriginX\*2)) local screenWidth = screenRight - screenLeft local screenHeight = screenBottom - screenTop ------------------------------------------------------------------------------------ -- FORWARD DELARE VARIABLES ------------------------------------------------------------------------------------ local rect, goTrans, buttonPress, button1, button2, button3 function goTrans() local targetY = centerY - screenHeight\*.25 if rect.y ~= centerY then targetY = centerY end transition.to(rect, {y = targetY, transition = easing.inOutSine, onComplete = goTrans}) end rect = display.newRect(centerX, centerY, screenWidth\*.25, screenWidth\*.25) function buttonPress(event) local target = event.target if target.pressed == nil then target.pressed = true transition.to(target, {alpha = 0, y = screenBottom}) if target == button1 then goTrans() transition.to(button2, {alpha = 1, y = centerY + screenHeight\*.25}) elseif target == button2 then transition.cancel(rect) transition.to(button3, {alpha = 1, y = centerY + screenHeight\*.25}) button3.pressed = nil elseif target == button3 then goTrans() transition.to(button2, {alpha = 1, y = centerY + screenHeight\*.25}) button2.pressed = nil end end return true end button1 = widget.newButton({ label = "start transition", shape = "roundedRect", fontSize = screenWidth\*.08, width = screenWidth \* .75, height = screenHeight \* .1, onRelease = buttonPress }) button1.x, button1.y = centerX, centerY + screenHeight\*.25 button2 = widget.newButton({ label = "cancel transition", shape = "roundedRect", fontSize = screenWidth\*.08, width = screenWidth \* .75, height = screenHeight \* .1, onRelease = buttonPress }) button2.x, button2.y = centerX, screenBottom button2.alpha = 0 button3 = widget.newButton({ label = "re-start transition", shape = "roundedRect", fontSize = screenWidth\*.08, width = screenWidth \* .75, height = screenHeight \* .1, onRelease = buttonPress }) button3.x, button3.y = centerX, screenBottom button3.alpha = 0

Although not mentioned in the maintenance log, Case 34162 is fixed in build 2376. (unless 34182 in the log was a typo).

I still have some further testing to do to see if all is well, but so far everything seems OK.

@CoronaLabs

FYI.

I rolled back the workarounds I had in place for the transition API issues, and they all seem to be fixed with build 2376.

Even the last one I reported above without an official bug report, however it looked like it was related to bug 34276 which was reported by @schroederapps, and was reported as fixed in build 2376 as well.

Thanks.

I’m a happy camper again.  :wink:

@ingemar: you’re welcome.

alex

I know you posted the bug # the other day, can I get it hear as a reference?

Thanks

Rob

Seriously?  Ingemar, if you have time, I’d be so grateful if you can describe what kind of weirdness you are seeing.

I submitted my latest app to Apple with 2014.2370 the night before, and I haven’t seen the issues I saw in 2014.2368 – but it could be that my testing is yet to hit a case that would cause the havoc you are seeing with transition.cancel().  If it is applicable to my app, I’d need to developer-reject the submission and resubmit with 2014.2354 (with which I tested my app most extensively so far.)

Naomi

The outstanding one is Case 34162.

(The fixed ones in build 2370 were 34032 and 34033)

However I think I’ve stumbled upon several more issues. It’s difficult to track what’s going on as the behavior is morphing depending on the statements I use. I’m also *sometimes* having issues with the Composer API that I haven’t seen before when changing scenes. Putting a gotoScene within a timer.performWithDelay(10,…) seems to bring back the original behavior, but I can’t understand why timing all of a sudden has become an issue. The problem here again is that it’s only certain scenes, and not all.

There also still seem to be issues with the transition API when using objects and tag-names in certain circumstances.

It’s all a bit frustrating, but I’m trying to track down these issues as fast as I can, because I don’t want to get stuck on build 2363.