Closed Bug 593680 Opened 14 years ago Closed 1 year ago

[meta] Tab animation perf issues

Categories

(Firefox :: General, defect, P5)

defect

Tracking

()

RESOLVED INACTIVE

People

(Reporter: stephane.demurget, Assigned: jrmuizel)

References

(Depends on 4 open bugs, Blocks 1 open bug)

Details

(Keywords: meta, perf, Whiteboard: [Snappy:P1])

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b6pre) Gecko/20100903 Firefox/4.0b6pre
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b6pre) Gecko/20100903 Firefox/4.0b6pre

I've hit a performance regression for the opening/closing tab animation.

This seems to be because of the new tab style.

In this build, everything is really smooth:

http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-linux/1283579728-20100903225528-2396696f1631-firefox-4.0b6pre.en-US.linux-i686.tar.bz2

In the following one, it's not (I only get ~3 frames drawn):

http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-linux/1283590742-20100904015902-bd474ff6f86c-firefox-4.0b6pre.en-US.linux-i686.tar.bz2


Reproducible: Always

Steps to Reproduce:
1.Get the second build.
2.
3.
Actual Results:  
The new tab style looks great but its animation are sluggish (well, certainly on older hardware).

Expected Results:  
Smooth opening/closing a tab as it was on the first build mentioned.

I've got a Celeron 1.6Ghz computer with the nouveau driver.

Is there any profiling tool I could use to provide more data?
See Also: → 572488
Depends on: 596954
Blocks: 596954
No longer depends on: 596954
I experience it on Win7, too. Especially when other tabs are loading.
I experience some of this sluggishness although only with D3D, DirectWrite and D2D enabled (which is by default for my hardware). Perhaps there is another bug for that somewhere?
Blocks: 572488
OS: Linux → All
Hardware: x86 → All
See Also: 572488
Bug 575056 & Bug 572488 added Opaqueness combined with -moz-linear-gradient Usage.
So isn't this rather a Core Perf Bug?
Blocks: 575056
No longer blocks: 575056
Nominating for blocking; I'm seeing this too, and this really hurts the perception of Firefox 4 IMO, since one of the first things users will do will be to open a new tab and watch the animation. If it's chunky, that's a bad first impression.
blocking2.0: --- → ?
Does it only happen when hardware acceleration is enabled? I'm not seeing it on my Win 7 machine, but I don't have HW accel enabled.

Speculatively moving to GFX based on comment 4, but if we could get some details on graphics H/W where we're seeing this and whether or not turning accel on or off (in Prefs > Advanced) that would help us confirm!
Component: Theme → Graphics
Product: Firefox → Core
QA Contact: theme → thebes
Using my framerate monitor addon I hacked together today [1], on my Linux netbook (Samsung NC10, two years old) I'm getting new tab animation framerates between 10 and 35 fps on a clean profile. On my work high-end MacBook Pro I'm getting 40-55 fps.

This doesn't seem fast enough to me. IMO we should be at 60 fps on high end machines, and at *least* 30 on the low end.

I profiled the new tab animation on Mac and it seems that we spend a lot of time in the blur code. I suspect we have too many shadows in the tab bar.

[1]: https://github.com/pcwalton/firefox-framerate-monitor
Just tried again: when switching back to Firefox after using something else in the foreground, on the same Linux netbook I get around 5-10 FPS for the new tab animation.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Graphics → Theme
Product: Core → Firefox
QA Contact: thebes → theme
Did we not at some point have a bug about detecting when the animation was taking too long and just skipping it? Perhaps I was dreaming.

cc'ing Shorlander and Dao to see if they believe there's a quick fix for the "too many shadows" assertion of comment 7.
We don't use box-shadow for tabs on any platform, so it would be interesting to know what exactly is being redrawn there.
Performance regression in primary UI responsiveness -> blocking+.
blocking2.0: ? → final+
Keywords: perf, regression
This bug is a mess. It was filed as a Linux theme regression (which I can't reproduce, maybe because I don't get accelerated layers on my netbook) and then changed to all platforms and Core:Graphics because people saw bad performance on Windows with hardware acceleration. Then Patrick profiled something on OS X and Joe moved the bug back to Firefox:Theme. Now it's blocking as a regression, which is fine theoretically, except that I have no idea what regression we're tracking.
This bug should be about the original report. If there are actually different causes for each OS, then there should be separate bugs for those to clarify what needs to be done in those other cases.
OS: All → Linux
Is it all Linux machines, or only older ones? If all Linux, please remove [softblocker] so we can reconsider that verdict.
Whiteboard: [softblocker]
Measuring with framerate-monitor, I'm getting 30fps routinely. However, I see real lag when opening a tab on a daily basis. Could be add-ons though :(
(In reply to comment #7)
> I profiled the new tab animation on Mac and it seems that we spend a lot of
> time in the blur code. I suspect we have too many shadows in the tab bar.

Dao, Shorlander: where would one disable all related styling to test this theory out?
(In reply to comment #16)
> (In reply to comment #7)
> > I profiled the new tab animation on Mac and it seems that we spend a lot of
> > time in the blur code. I suspect we have too many shadows in the tab bar.
> 
> Dao, Shorlander: where would one disable all related styling to test this
> theory out?

We don't use shadows in the tab bar, see comment 10. Also, this bug is about Linux.
** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue without a requirement for beta coverage
blocking2.0: final+ → .x+
This is an issue also under Windows.
OS: Linux → All
Whiteboard: [softblocker] → [softblocker][Snappy]
Jeff, can you triage this? Ie if this something we can fix by tweaking css, should it be a P1?
Assignee: nobody → jmuizelaar
Whiteboard: [softblocker][Snappy] → [softblocker][Snappy:P2]
Whiteboard: [softblocker][Snappy:P2] → [softblocker][Snappy:P1]
(In reply to Marco Castelluccio from comment #19)
> This is an issue also under Windows.

Ok. I'll now give up trying to keep this bug focused on the regression allegedly caused by bug 572488.
No longer blocks: 572488
Keywords: regression
Summary: New tab style animation perf regression → Tab animation perf issue
See Also: → 708788
Summary: Tab animation perf issue → Tab animation perf issues
Depends on: 713287
Depends on: 633157
Depends on: 599711
Depends on: 708788
From the last 10 to 12 days, in the latest Nightly, just after clicking on the close button or hitting the middle mouse button on a tab to close it, the close button of the tab quickly shifts to the left of the closing tab, thus now making two close buttons close to each other, the Title text of the tab disappears ans the tab's width starts decreasing. But then the close button creates a jerk as when the tab's width reaches that of the close button, the close button disappears.It would have been a lot smoother if the close button were to disappear along with the title text and the closing animation would continue smoothly.I am on Windows 7 , latest Nightly 32 bit and HWA enabled.Didn't know where to bring up this topic so just commenting here.
(In reply to scrapmachines from comment #22)
Please file a new bug.
Depends on: 720673
Depends on: 724349
Depends on: 750417
Depends on: 763289
Depends on: 790966
Depends on: 791637
Depends on: 648789
No longer depends on: 791670
Also, dlbi (bug 539356) will likely improve the tab animations.
Depends on: 684861, 663395, 753559
No longer depends on: 753559
No longer depends on: 790840
Depends on: 792922
Depends on: tabswitch
Depends on: australis-tabs-win
Blocks: 771444
blocking2.0: .x+ → ---
Component: Theme → General
Keywords: meta
Whiteboard: [softblocker][Snappy:P1] → [Snappy:P1]
No longer depends on: 743069
No longer depends on: 791637
Depends on: 750871
Depends on: 1015756
Depends on: 998279
Is this meta bug still relevant?
Flags: needinfo?(jaws)
So much has changed with how we draw our tabs over the last three years, let alone over the last eight years. I would say this meta bug is not relevant (some of the bugs blocking this may still be) but we have other meta bugs tracking tab performance which are more up-to-date.
Flags: needinfo?(jaws)
Priority: -- → P5
Summary: Tab animation perf issues → [meta] Tab animation perf issues
No longer depends on: 648789
Severity: normal → S3

Closing per comment 27

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.