Closed Bug 724349 Opened 13 years ago Closed 13 years ago

tab closing animation got slower from Fx 12 to Fx 13

Categories

(Firefox :: Tabbed Browser, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: dietrich, Unassigned)

References

Details

(Whiteboard: [snappy:p1])

screenshot of telemetry reports: http://cl.ly/2Q432Z2U0I1K1T3c3H2K
Component: General → Tabbed Browser
QA Contact: general → tabbed.browser
Chris - was told you knew of a bug about transitions+gradients being slow. Would that impact this bug?
Whiteboard: [snappy]
On android (and gonk), we use pixman's gradient drawing code, which isn't really optimized. If the regression here is for OS X, then we use different code to draw gradients so that shouldn't be an issue. We currently over-invalidate elements that are positioned with CSS transforms. That's bug 722923. That affects transitions on transforms too.
Blocks: 593680
Blocks: 725817
Can a new way of tab closing be considered ? Which might deal with such problems arising due to colors, gradients and transforms ? What I suggest is that while closing the tab, instead of having a width transition on the closing tab along with the position transition on the tab just next to the closing tab (all on the tab strip) , this is what I suggest: 1. As soon the user tries to close the tab (by clicking on cross, or middle mouse click on tab or any other way if possible), remove the tab all together from the tab strip (by any means : collapsing/display:none/removeChild). 2. As soon as the tab is removed (may be instantaneously), start shifting the next tab to its position. This way we would reduce the drawing/calculation/computations while closing the tab without hindering the whole quality/style of tab close animation. If we can add a transition to the make the tab (being closed) fade out/become invisible, then it would even look better than what happens right now. I don't know is this is the right place for such suggestion, but it might help in performance of tab closing animation.
Whiteboard: [snappy] → [snappy:p1]
Can someone try and narrow down exactly what change caused this?
Dao, do you know of anything in how we animate tabs that has changed recently or would cause this?
(In reply to Dietrich Ayala (:dietrich) from comment #5) > Dao, do you know of anything in how we animate tabs that has changed > recently or would cause this? nope Does this affect all OSes?
(In reply to Dietrich Ayala (:dietrich) from comment #5) > Do you know of anything in how we animate tabs that has changed > recently or would cause this? My idea (albeit it may be crazy), is that this might be due to the addition of the conditional forward button. Given the following situation: Scenario: Tab A is selected and has the forward button visible Tab B has the forward button hidden Steps: Closing tab A will cause tab B to become visible, and will force the SVG mask of the urlbar to apply. This application may delay the showing of the tab and cause jankiness. I'll see if there is a way that I can write a test to check the timings here.
I do not have the conditional forward button as I have the home button in between unified back forward button and urlbar-container. But still while closing a foreground tab I can see regression in tab closing animation. This regression is minimal in case of closing a background tab PS: By background I mean tab whose content is not currently visible or rather tab without focus. and foreground tab is vice versa.
Is there anything QA can do to help here? I see that a regression-window is being asked for but I can't see a reproducible test case. @scrapmachines, since you can see this issue locally, would you be willing to do some regression testing via mozregression? http://harthur.github.com/mozregression/ I can help you if you want.
telemetry evolution screenshots: Aurora: http://cl.ly/3F3g070n37373N0j241S Nightly: http://cl.ly/3v121o1h0W3b1F2z3b2a Nightly regression range hit users between 1/11 and 1/20ish, it looks like. Not sure about the best way to reproduce. Could install about:telemetry, open a bunch of tabs and close them all, then look at the FX_TAB_ANIM_CLOSE_MS values and compare to previous builds. It's pretty manual, but I don't have a better suggestion right now :/
I've just tried with an old windows xp machine (2GHz single cpu, 1GB RAM, NVIDIA GeForce 6), where the closing animation is really slow. When I close a tab, at the beginning the title text disappears but the tab still remains for some time (~1s). This is really bad for perceived performance. Sadly I haven't direct access to this machine, so I can't test to see when the regression occurred.
(In reply to Marco Castelluccio from comment #11) > I've just tried with an old windows xp machine (2GHz single cpu, 1GB RAM, > NVIDIA GeForce 6), where the closing animation is really slow. > When I close a tab, at the beginning the title text disappears but the tab > still remains for some time (~1s). This is really bad for perceived > performance. > > Sadly I haven't direct access to this machine, so I can't test to see when > the regression occurred. do you know if gfx acceleration is on on that machine?
(In reply to Taras Glek (:taras) from comment #12) > (In reply to Marco Castelluccio from comment #11) > > I've just tried with an old windows xp machine (2GHz single cpu, 1GB RAM, > > NVIDIA GeForce 6), where the closing animation is really slow. > > When I close a tab, at the beginning the title text disappears but the tab > > still remains for some time (~1s). This is really bad for perceived > > performance. > > > > Sadly I haven't direct access to this machine, so I can't test to see when > > the regression occurred. > > do you know if gfx acceleration is on on that machine? I'm pretty sure it's blocked because of old drivers. Here's a video (I know it's rough) that shows what is the problem of the animation (note this is on my fast machine, on the Windows XP one it's a lot (~ ten times) slower and more noticeable): http://dl.dropbox.com/u/34104919/20120501_001230.mp4
Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0 http://vid.ly/5g9s7p This is how it currently looks like on a Windows XP with Intel(R) 82945G Express Chipset Family (blocked graphics driver) using Firefox 13 beta2. With New tab enabled, that is. Looks a lot more smooth with about:blank. I can also reproduce this (sluggish close tab animation) when closing the focused middle tab in a tab set (Linux with NVIDIA Corporation -- GeForce 8400 GS/PCIe/SSE2 - not blocked). On the Windows XP computer, I can also see a sluggish tab opening animation - only with new tab enabled. Would it make sense to log a new issue for that or would this bug cover that also?
(In reply to Virgil Dicu [:virgil] [QA] from comment #14) > Would it make sense to log a new issue for that > or would this bug cover that also? This bug certainly doesn't cover your issue. This is about a regression in Firefox 10.
(In reply to Dão Gottwald [:dao] from comment #15) > (In reply to Virgil Dicu [:virgil] [QA] from comment #14) > > Would it make sense to log a new issue for that > > or would this bug cover that also? > > This bug certainly doesn't cover your issue. This is about a regression in > Firefox 10. But the point is, that Fx 10 is already out and old, Fx 12 is the current version, still the tab closing animation lag is not fixed. IMO, this bug should be made in general. Like : Tab closing animation got slower after Firefox 9. And the problem is not just the new tab page. In fact, the IMO the new tab page is one of the last problems causing the lag.
No, this bug keeps tracking the regression it was reported for. Other regressions belong in separate bugs.
Logged bug 752837 and bug 752839 for tab closing animation and tab opening animation.
Virgil, can you try this in firefox 9?
(In reply to Taras Glek (:taras) from comment #19) > Virgil, can you try this in firefox 9? Attempted a simple manual test comparation between F9 and F13b2 on Windows XP (the same configuration as in comment 14). Tried to open/close several complex sites both with about:newtab (in F13) and about:blank (in F13 and F9). Used a clean profile. I can't observe a noticeable difference between about:blank in F9 and F13. But can see one with about:newtab enabled in F13 - the tab closing animation seems smoother for me with about:blank in F9. With a clean profile, the difference is not that severe - see comment 14 for a reference with an older profile.
Would like to compare values using about:telemetry between the 2 builds - that would give more useful results. But using about:telemetry in F9.0 i can't get any results for tab closing/opening animation. The same version works for F13 (https://addons.mozilla.org/en-US/firefox/addon/abouttelemetry/) Can anyone point me to a version that works with F9? I've tried installing older versions, but did not manage to get the measurement I was referring above in F9.
(In reply to Virgil Dicu [:virgil] [QA] from comment #21) > Would like to compare values using about:telemetry between the 2 builds - > that would give more useful results. But using about:telemetry in F9.0 i > can't get any results for tab closing/opening animation. The telemetry probe for new/close tab animations landed in version 11 (bug 708788).
Then what exactly does http://cl.ly/2Q432Z2U0I1K1T3c3H2K show?
(In reply to Dão Gottwald [:dao] from comment #23) > Then what exactly does http://cl.ly/2Q432Z2U0I1K1T3c3H2K show? Actually I don't know how the values were taken. Anyway, what I wanted to say is that if Virgil wants to see the telemetry values in Firefox 9 he can build it with the patch in bug 708788.
(In reply to Dão Gottwald [:dao] from comment #23) > Then what exactly does http://cl.ly/2Q432Z2U0I1K1T3c3H2K show? It shows that there was a bug in metrics dashboard, that stuck release labels on prerelease data resulting in versions being off by 3. I think The regression is between 12-13.
Summary: tab closing animation got slower from Fx 9 to Fx 10 → tab closing animation got slower from Fx 12 to Fx 13
Vigil, sorry, for misleading you about testing Firefox 9. Our tools were showing misleading info at the time the screenshot was taken. Dao, the telemetry data on aurora/beta is not helpful this regression. There is a change in the pattern, but it's not terrible. I think we should RESOLVED/INVALID this bug, and focus on making the animation more performant in bug 753139. Feel free to reopen the bug if you disagree.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.