Description: When the user has multiple apps ( or browser windows) open, they observe that when opening the 'Card View' (or 'Show Windows') functionality of Window Management, that gesturing between cards has become loose. Cards tend to shake when you gesture between them, sometimes graphical hitches occur where the cards will flash across another. It was also observed of an app 'lingering' in view and slowly peeling off the screen. Repro Steps: 1) Update a Flame to 20150427010202 2) Open a handful of apps 3) Hold home button to open card view 4) Gesture between cards --- or --- 1) Update a Flame to 20150427010202 2) Open the Browser 3) Navigate around and open multiple windows (3+) 4) Hold '...' and find 'Show Windows' 5) Gesture between cards/windows in this view Actual: Card View gestures make cards/windows shake, exhibit graphical faults when navigating. ** effects seem heightened when a 'stronger' gesture is given that would throw the card further than the UI will allow it Expected: Card View gestures elicit smooth motion from the cards/windows being maneuvered. No sudden shaking of cards. Environmental Variables: --------------------------------- Device: Flame 3.0 Build ID: 20150427010202 Gaia: b4c949cdc780893897c9b45c1adea46e2eb694ff Gecko: 37d60e3b8be6 Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b Version: 40.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0 Device: Flame 2.2 BuildID: 20150427002504 Gaia: 265ca0bc9408c21fc4b25a259fcee7fb642cd06b Gecko: 1908685d798d Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429 Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 --------------------------------- Issue does not occur on flame for 2.1 devices: Results: Card View has larger cards and is slower to navigate Device: Flame 2.1 BuildID: 20150427001201 Gaia: bbe983b4e8bebfec26b3726b79568a22d667223c Gecko: 82a14be0462c Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429 Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 --------------------------------- Repro frequency: 5/5 See attached: video- https://youtu.be/b6rg1yn2mT8 logcat

Noticed this as well. Seems like a regression.

[Blocking Requested - why for this release]: Visible UX regression. Nominating to block 2.2

I have a hard time deciding whether the build is broken or not, as the difference between builds during the card view transition does not seem to be clear. Here's my initial regression window, which I'm not quite confident about. Leaving my name off for someone else to try. Initial Regression Window: Last Working Environmental Variables: Device: Flame 3.0 BuildID: 20150211221340 Gaia: d5a71cedb37dd45f439f672489db3994b349ac43 Gecko: 3094601af679 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 First Broken Environmental Variables: Device: Flame 3.0 BuildID: 20150212064620 Gaia: 2a2b008f9ae957fe19ad540d233d86b5c0b6829e Gecko: 81f979b17fbd Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Last Working Gaia First Broken Gecko: Issue DOES reproduce Gaia: d5a71cedb37dd45f439f672489db3994b349ac43 Gecko: 81f979b17fbd First Broken Gaia Last Working Gecko: Issue does NOT reproduce Gaia: 2a2b008f9ae957fe19ad540d233d86b5c0b6829e Gecko: 3094601af679 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3094601af679&tochange=81f979b17fbd

Botond, might this be coming from 1127066?

Sounds like a dupe of bug 1155785 to me.

Lets wait fore bug 1155785. Adding naoki to see how bad it is.

It is kinda bad visually, and I've had the browser window close on me a few times. ( I think due to LMK ) I updated my gaia to the most recent and ran into Bug 1159539; I'm not 100 % sure if it's valid. Will need to check on it again tomorrow.

All the testers that have worked on this bug have a hard time deciding whether a build is reproducing the bug or not. We also suffered with dizziness from staring at the screen with cards moving rapidly on it for long periods of time. I think it's time we give up on working on this window.

I figured out the LMK issue with the app is bug 1155854. The shake happens when you initially go into card view and swipe. it happens more so with 512 mb flame and you can see content on browser starts lagging ( from the video ) : https://www.youtube.com/watch?v=_5sKSS0Ajc0 Gaia-Rev 6e35b0948c42a4398b8a5916015de167121683a1 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/1ad65cbeb2f4 Build-ID 20150429010205 Version 40.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20150429.044126 FW-Date Wed Apr 29 04:41:37 EDT 2015 Bootloader L1TC000118D0

needinfo on myself to check 2.2.

I can still reproduce in 2.2; it occurs more when you first launch task manager. Gaia-Rev aa1da5036f9425c25d515d14243d3473bfefb4fd Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/38b2838d43e1 Build-ID 20150430002504 Version 37.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20150430.042218 FW-Date Thu Apr 30 04:22:29 EDT 2015 Bootloader L1TC000118D0

Given the difficulties described in comment 3 and comment 8, the regression window in comment 3 may not be accurate. It's also not straightforward for me to test whether this has something to do with bug 1127066 by backing that bug out locally, because many things that depend on it have landed since it landed. That said, I can do some investigation on this bug.

My first thought was to get a profile with '-layersdump' to capture layer trees for each frame of the stutter (and be able to associate the trees with the frames visually), but I can't reproduce the problem with the profile running in '-layersdump' mode (while I *can* repro the problem, intermittently, while running normally). Since capturing layer textures slows the phone down considerably, this might indicate that the problem is caused by some sort of race which doesn't get a chance to occur at the slower composition rate that we get when capturing textures.

The following is a trace of how the transform and shadow-transform of a single card change over a sequence of composites in response to a swipe that stutters: transform=[ 1 0; 0 1; -139 222; ]] shadow-transform=[ 1 0; 0 1; -139 222; ]] transform=[ 1 0; 0 1; -139 222; ]] shadow-transform=[ 1 0; 0 1; -139 222; ]] transform=[ 1 0; 0 1; -49 222; ]] shadow-transform=[ 1 0; 0 1; -46.9033 222; ]] transform=[ 1 0; 0 1; -49 222; ]] shadow-transform=[ 1 0; 0 1; -37.2688 222; ]] transform=[ 1 0; 0 1; -49 222; ]] shadow-transform=[ 1 0; 0 1; -27.6344 222; ]] transform=[ 1 0; 0 1; -49 222; ]] shadow-transform=[ 1 0; 0 1; -18.0074 222; ]] transform=[ 1 0; 0 1; -49 222; ]] shadow-transform=[ 1 0; 0 1; -8.36946 222; ]] transform=[ 1 0; 0 1; -49 222; ]] shadow-transform=[ 1 0; 0 1; 1.25783 222; ]] transform=[ 1 0; 0 1; -49 222; ]] shadow-transform=[ 1 0; 0 1; 10.8921 222; ]] transform=[ 1 0; 0 1; -49 222; ]] shadow-transform=[ 1 0; 0 1; 20.5264 222; ]] transform=[ 1 0; 0 1; -49 222; ]] shadow-transform=[ 1 0; 0 1; 27.5 222; ]] transform=[ 1 0; 0 1; -49 222; ]] shadow-transform=[ 1 0; 0 1; 27.5 222; ]] transform=[ 1 0; 0 1; -49 222; ]] shadow-transform=[ 1 0; 0 1; 27.5 222; ]] transform=[ 1 0; 0 1; -49 222; ]] shadow-transform=[ 1 0; 0 1; 27.5 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; -32.9927 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; -12.5709 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 7.86378 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 28.2921 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 48.73 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 69.1755 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 89.5945 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 110.024 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 125 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 125 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 125 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 125 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 125 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 125 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 125 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 125 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 125 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 125 222; ]] transform=[ 1 0; 0 1; -37.2688 222; ]] shadow-transform=[ 1 0; 0 1; 125 222; ]] transform=[ 1 0; 0 1; 125 222; ]] shadow-transform=[ 1 0; 0 1; 125 222; ]] transform=[ 1 0; 0 1; 125 222; ]] shadow-transform=[ 1 0; 0 1; 125 222; ]] The transform reflects what Layout is doing, and the shadow-transform reflects what the compositor is doing. The interesting bit is the x-coordinate of the translation, which starts at -139 before the swipe and ends up at 125 when the swipe is complete. Both the transform and the shadow-transform start and end there. The transform goes through the intermediate values of -49 and -37, indicating that Gecko got a chance to repaint twice during the swipe. These values form an increasing sequence, as they should. The shadow-transform undergoes additional intermediate values, indicating that the swipe is being animated in the compositor. However, unlike the values on the layout side, the compositor values do not form an increasing sequence - they increase from -139 to 27.5, then jump back down to -32.9 and continue increasing from there to the final 125. This jump from 27.5 to -32.9 is the stutter. The stutter occurs on the first composite that happens after the layer-transaction with the -37 value from Layout comes in. This suggests that the problem has to do with how Layout and the compositor coordinate the async animation.

I also verified that there is no APZ scrolling going on, so the only contributor to the shadow-transform should be OMTA, suggesting that this is an OMTA issue. I'm going to be away next week; needinfoing Brian and Matt, in case one of them is able to help with this. If not, I will continue investigating when I come back.

We don't actually take the transform into account when computing OMTA shadow-transform values, we just use the startTime of the animation and the current compositor sample time. As far as I can tell, the compositor sample time should be monotonically increasing (it's using TimeStamp::Now()), so this should only happen if the start time for the animation changes. It's not obvious how that would happen, but I don't know much about the animation code.

Let's see what Brian thinks when he comes back.

Comment 14 is very helpful. It seems likely that we're re-sending a different animation start time in the second layer transaction. This would only happen after bug 927349. Bug 1123196 should have fixed it so that we always send the same start time but I guess that's not happening in this case. Looking at bug 1123196 comment 16, there may be some other combination of nested iframes/-moz-element/layer managers that causes us to resolve this start time twice.

It turns out what's happenning is that while the transition is still running (at least as far as the content process is concerned) new transitions are being created. However, those new transitions are being created with their start point as the value of transform as seen by the content process. When the compositor process gets ahead of the content process you'll see stutter. Taking the example from comment 14 the process is something like this: Content frame t=0ms: * Process touch event * Script updates the transform property to 'translateX(27.5px)' (Or something similar depending on what the units being reported in comment 14 are.) * Create new CSS transition of dur 200ms with, as yet, unresolved start time (For my reference, typical transition durations are 27ms, 38ms, 50ms, 72ms, 100ms, 200ms, 500ms. Sometimes there is a positive delay too.) Animation keyframes: { transform: translateX(-139px) } { transform: translateX(27.5px) } * Do painting * End layer transaction * Resolve start time of animations on layers at 20ms (This is just for argument, it doesn't really matter how long this takes since we don't time animations until painting has finished.) [ Upload animations etc. to compositor ] * Mark animations with a pending start time ("ready time") of 20ms Compositor: * Receive layer update * Add new animations with start time t=40ms Compositor frame t=158ms: (I'm basing this on the values in comment 14. I'm not sure why we're taking so long to composite the first frame in this case but I wonder if we're doing some expensive upload since the content process and compositor process are equally lagged here. Alternatively, and probably more likely, we might be updating the specified transform style and triggering a style flush without painting such that the keyframes for the animation are actually between say, -60px and 27.5px.) * Composite frame at 138ms progress, transform: translateX(-47px) Compositor frame t=174ms: * Composite frame at 154ms progress, transform: translateX(-37px) ... Compositor t=270ms: * Composite frame at 250ms progress, transform: translateX(27.5px) (From this point on the compositor will keep applying the same value since compositor animations fill forwards until they are taken off the layer by the content process.) (During this time the content process seems to be quite busy. It's true that we suppress style updates on the main thread when they're running on the compositor but we *don't* do that when the animation reaches the end. As a result, we *can't* have composited a frame at t>270ms or else we would triggered a layer transaction that pulled the animation off the compositor.) Content frame t=178ms: * Process next touch event * Script updates the 'transform' property to 'translateX(125px)' * Process style updates which causes the content process to calculate the current animated transform value of 'translateX(-37px)' * Create new CSS transition of dur 80ms with, as yet, unresolved start time Animation keyframes: { transform: translateX(-37px) } { transform: translateX(125px) } (In nsTransitionManager.cpp we detect we have an existing transition on the transform property but we only do special handling when the new transition ends at the start point of the previous animation.) * Do painting * End layer transaction * Resolve start time of animations on layers at sometime after 178ms [ Upload animations etc. to compositor ] * Mark animations with a pending start time ("ready time") of sometime after 178ms Compositor: * Receive layer update * Here we clobber the existing (finished) animations with the new ones (In my observations the difference in start time between the old and new animations is about 50ms so either the data in comment 14 is a particularly lagged case or the initial transition is, indeed, not starting from -139px as I suspect.) Compositor frame t=~180ms * Composite frame at 5ms progress, transform: translateX(-33px) !! Hence, the stutter.

Long-term there are a few things we plan to do about this: * Implement scroll and touch driven animations. * Implement additive animations (some people have been experimenting with the Web Animations implementation of additive animations and using them to creating animations that automatically adapt to changes and are calling this pattern "relative animations" or "negative delta animations"). Short-term things we could do: * Gecko-side: If we detect that we're replacing a transition that is running on the compositor, re-evaluate the "from" value using the current timestamp. I don't like adding these special cases but we already do this for pausing in some circumstances (e.g. see the big comment in the middle of Animation::ComposeStyle where we use the current timestamp while pausing to prevent flicker). This one could get pretty tricky though since we'd probably have to handle the case when, according to the current timestamp, the animation has finished. * Gaia-side: Can we rework this interaction somehow to only trigger one transition at a time? Alternatively, if we can work out what is keeping the content process so busy and reduce that we'd minimise the chance of stutter. I suspect this isn't strictly a regression but that prior to bug 927349 we didn't get enough frames to notice this. Adding dbaron in case he has any suggestions, particularly regarding the possibility of adding special handling to Gecko for this.

One further thought, we could just pass an empty "from" value to the compositor in this case and let the compositor fill it in with whatever it believes to the current value at the time it receives it.

(In reply to Brian Birtles (:birtles) from comment #21) > One further thought, we could just pass an empty "from" value to the > compositor in this case and let the compositor fill it in with whatever it > believes to the current value at the time it receives it. I think this is probably the right approach although we might not always have all the information needed to reconstruct the keyframe on the compositor. It might be better to simply annotate keyframes that were constructed from the underlying/current value as such and pass that flag onto the compositor. If the compositor has a running animation it can use that to replace the keyframe in question. That said, this is not a small change and might not be suitable for 2.2. For that a Gaia fix would probably be better. Can we just rework this interaction so it doesn't produce any overshoot animation (i.e. no flinging, just tracking the finger) until we get a touchend event?

(In reply to Brian Birtles (:birtles) from comment #22) > That said, this is not a small change and might not be suitable for 2.2. For > that a Gaia fix would probably be better. Can we just rework this > interaction so it doesn't produce any overshoot animation (i.e. no flinging, > just tracking the finger) until we get a touchend event? ni?sfoster

Forwarding ni? to Etienne

(In reply to Botond Ballo [:botond] from comment #23) > (In reply to Brian Birtles (:birtles) from comment #22) > > That said, this is not a small change and might not be suitable for 2.2. For > > that a Gaia fix would probably be better. Can we just rework this > > interaction so it doesn't produce any overshoot animation (i.e. no flinging, > > just tracking the finger) until we get a touchend event? > > ni?sfoster We don't really have flinging (ie. you can't move more than one step with one gesture), but we center cards on touchend. That said, just made a patch removing a bunch of old tricks and making sure we always have a `transition: transform` set on the cards and looks like it's helping a lot. Coming soon :)

Comment on attachment 8605253 [details] [gaia] etiennesegonzac:bug-1158928 > mozilla-b2g:master What do you think? It's a pretty safe patch and it might make things bearable until Jet finishes [1] ;) [1] https://github.com/jetvillegas/gaia/tree/APZC-card-view

(In reply to Etienne Segonzac (:etienne) from comment #27) > It's a pretty safe patch and it might make things bearable until Jet > finishes [1] ;) > > [1] https://github.com/jetvillegas/gaia/tree/APZC-card-view Cool, I was going to start work on that next week (bug 1161229)

Comment on attachment 8605253 [details] [gaia] etiennesegonzac:bug-1158928 > mozilla-b2g:master Works for me, certainly its an improvement and fixes the reported problem. Now that the panning is fixed, I'm noticing the "overscroll" at the edges seems to lack a little friction. But I think these are nits we can work out on master. Thanks!

Autolander could not locate a review from a user within the suggested reviewer list. Either the patch author or the reviewer should be in the suggested reviewer list.

Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/52edb910451301d2e7ac29a28c486c888e65eb3a

Comment on attachment 8605253 [details] [gaia] etiennesegonzac:bug-1158928 > mozilla-b2g:master [Approval Request Comment] [Bug caused by] (feature/regressing bug #): unsure but probably revealed by platform changes [User impact] if declined: worse than usual card view experience [Testing completed]: manual tests of cards view scenarios, we don't have the tools to to automated transition performance testing. [Risk to taking this patch] (and alternatives if risky): low, removing hacks :) [String changes made]: none

Hi Norry, Please verify on master. Thanks

This bug has been verified as pass on latest build of Flame v3.0. See attachments: verify_v3.0.mp4 Reproduce rate: 5/5 Device: Flame 3.0 (Pass) Build ID 20150517010201 Gaia Revision 4c0f36e9dfe017bf2a698d416a57c8156b43383d Gaia Date 2015-05-15 22:18:51 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/2f6ea66057fe Gecko Version 41.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150517.044012 Firmware Date Sun May 17 04:40:23 EDT 2015 Bootloader L1TC000118D0

Comment on attachment 8605253 [details] [gaia] etiennesegonzac:bug-1158928 > mozilla-b2g:master Approving and QA please verify after patch land on 2.2.

v2.2: https://github.com/mozilla-b2g/gaia/commit/21625a3cd40bdfaf724ff0c38fe5fae54882b516

This bug has been verified as pass on latest build of Flame v2.2 & Nexus5 v2.2. See attachments: verify_v2.2.mp4 Device: Flame v2.2 (Pass) Build ID 20150519162501 Gaia Revision 63e9eeec3032318f8a240f80b6a184fa4b50b6e1 Gaia Date 2015-05-19 17:52:15 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/4e078e1364d3 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150519.200807 Firmware Date Tue May 19 20:08:18 EDT 2015 Bootloader L1TC000118D0 Device: NEXUS5 v2.2 (Pass) Build ID 20150519162501 Gaia Revision 63e9eeec3032318f8a240f80b6a184fa4b50b6e1 Gaia Date 2015-05-19 17:52:15 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/4e078e1364d3 Gecko Version 37.0 Device Name hammerhead Firmware(Release) 5.1 Firmware(Incremental) eng.cltbld.20150519.195445 Firmware Date Tue May 19 19:55:01 EDT 2015 Bootloader HHZ12f

Regarding the Gecko fix suggested in comment 21 and comment 22, I filed bug 1167519 for this.