@Brent Yes its 100% what Ingemar and some others are describing. Not sure if it covers the all the problems in the thread.
In addition if you transition the object directly the alpha will transition normally, bug only applies to transitioning groups.
I can confirm that the problem for me applies to transitioning alpha values while also transitioning the object off screen.
If I hardcode alpha=0 when transitioning offscreen and alpha=1 when coming back the objects are displayed properly.
We have been trying to find some workarounds at our office over the past couple of days but nothing yet, will post if we find anything. In the meantime we have been able to replicate our specific issue a bit more.
In one of our screens we have a scrollview which contains a number of display objects, and this is where the issue is most damaging. New objects used to fade in using transition.to but we removed that in case it was causing the issue. We then tried toggling the alpha of these objects from 0.0 to 1.0 in case it was an issue with some internal dirty flag, but the issue still occurred. During testing, I tried switching scene using a “cross-fade” storyboard transition whilst the scrollview was scrolling to the top of its contents, and upon returning to the scene with the scrollview in it I found that some of the display objects contained within it were at varying levels of alpha, not just 1.0 or 0.0.
To summarise, no objects in the scene have any transition applied to them and all objects have either no alpha or full alpha, so there should be no circumstance where by some objects are translucent. I believe that the only place that the alpha can be changed is during the internal scene transition and that maybe there’s a bug when multiple transitions are applied to an object? e.g. (the storyboard transition and the scrollview transition)
I am having a similar issue with transition.to() under the new graphics engine. In my scenario, I have a group containing a number of object types, including a snapshot object. On relatively rare occasions, the group would NOT appear when I transition the alpha for the group from 0 to 1. I have a number (30) of these groups on screen at the same time, and most often all of them appear correctly. However, if one is invisible, more than likely all of them will be invisible, but sometimes a few will appear, while others will be invisible.
I have confirmed via print statements that the group has property ‘.isVisible’ set to true, even although the group is sometimes not appearing.
At first I thought it was a problem with overlapping transitions, as this could sometimes cause weird behavior. But after trying to track down that possibility, I found that SOMETIMES, some of the parts of the snapshot would appear, while others would not. (The objects that formed the snapshot are gone at this point) This should never happen, and is not something I could do in code, at least anyway that I know of. This ‘partial snapshot’ is much more rare than the entire group being invisible.
If I force the groups to group.segment = .3, instead of 0, just before the transition, the problem becomes much more rare, happening 1 time in 100 instead of 1 time in 10.
I am using the ‘tag’ transition cancel feature just before this problem appears, and I am a little suspicious of it being related somehow.
Unfortunately, it would be pretty difficult to cut the offending code out to create a simpler fail case.
So, I am wondering who else has snapshots in their group, or maybe a transition tag cancel in the vicinity of this problem(?)
Hope this helps!
Has anyone noticed this happen with more regularity when using ‘fade’ or ‘crossFade’ transition effects?
I am only using a ‘fade up’ transition… that is, a transition from a low alpha to an alpha of 1, over 300 milliseconds.
Has anybody filed a test case and bug report with a simple provable case? We’re going to need that before we can accurately investigate it.
Thanks,
Brent
What is the number on that bug report? I can’t seem to locate it in our database (or perhaps I’m searching for the wrong query).
Brent
It is 28784.
I’m not sure, but can this be a clue to why it’s happening?
If you run this code, you’ll see that the last iteration of a transition is never called ( t never becomes tMax ):
local rect = display.newRect(0, 0, 100, 100) rect:setFillColor(1, 1, 1, 1) rect.x = display.contentCenterX - 100 rect.y = 50 local rect1 = display.newRect(0, 0, 100, 100) rect1:setFillColor(1, 1, 1, 1) rect1.x = display.contentCenterX + 100 rect1.y = 50 local function transitionF(t, tMax, start, delta) print(t, tMax, start, delta) local cy = start + delta \* t / tMax rect1.y = cy return cy end transition.to(rect, {time = 200, y = 300, transition = transitionF})
Console output:
2013-12-14 15:31:38.651 Corona Simulator[19283:507] 0.066000000000003 200 50 250
2013-12-14 15:31:38.667 Corona Simulator[19283:507] 15.884 200 50 250
2013-12-14 15:31:38.686 Corona Simulator[19283:507] 34.942 200 50 250
2013-12-14 15:31:38.713 Corona Simulator[19283:507] 62.658 200 50 250
2013-12-14 15:31:38.727 Corona Simulator[19283:507] 76.281 200 50 250
2013-12-14 15:31:38.743 Corona Simulator[19283:507] 92.605 200 50 250
2013-12-14 15:31:38.759 Corona Simulator[19283:507] 108.819 200 50 250
2013-12-14 15:31:38.776 Corona Simulator[19283:507] 125.142 200 50 250
2013-12-14 15:31:38.792 Corona Simulator[19283:507] 141.021 200 50 250
2013-12-14 15:31:38.808 Corona Simulator[19283:507] 157.038 200 50 250
2013-12-14 15:31:38.824 Corona Simulator[19283:507] 172.871 200 50 250
2013-12-14 15:31:38.839 Corona Simulator[19283:507] 188.705 200 50 250
Build 2014.2130 appears to have fixed this issue for me.
Thank you!
Seems to be a bug in the latest build as previous build I didn’t have this issue. Mine is a bit different. I set an object alpha to 0 just before creating another different named object then doing a transition movement with that, but the first object alpha remains as 1 visually.
@Brent were you able to locate the bug report? Is there anything else we can provide to get this moving?
Hi @max84,
Yes, I located the report and we’re looking into it. Thanks to all for describing the symptoms in detail.
Brent
Build 2014.2130 appears to have fixed this issue for me.
Thank you!