Status

()

Firefox
General
7 years ago
a year ago

People

(Reporter: Stéphane Démurget, Assigned: jrmuizel)

Tracking

(Depends on: 13 bugs, Blocks: 2 bugs, {meta, perf})

Trunk
meta, perf
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Snappy:P1])

(Reporter)

Description

7 years ago
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?
(Reporter)

Updated

7 years ago
See Also: → bug 572488

Comment 1

7 years ago
Taking the build given in comment 0 gives:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2396696f1631&tochange=bd474ff6f86c
Depends on: 596954

Updated

7 years ago
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: bug 572488
Bug 575056 & Bug 572488 added Opaqueness combined with -moz-linear-gradient Usage.
So isn't this rather a Core Perf Bug?
Blocks: 575056

Updated

7 years ago
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.

Updated

7 years ago
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]

Comment 20

6 years ago
Jeff, can you triage this? Ie if this something we can fix by tweaking css, should it be a P1?
Assignee: nobody → jmuizelaar

Updated

6 years ago
Whiteboard: [softblocker][Snappy] → [softblocker][Snappy:P2]

Updated

6 years ago
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: → bug 708788

Updated

6 years ago
Summary: Tab animation perf issue → Tab animation perf issues

Updated

6 years ago
Depends on: 713287

Updated

6 years ago
Depends on: 633157

Updated

6 years ago
Depends on: 599711

Updated

6 years ago
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

Updated

5 years ago
Depends on: 790966
Depends on: 786484, 649218, 790840, 743069, 753139, 790567, 774717, 783064, 627159, 783328, 783656
No longer depends on: 790966, 763289
Depends on: 791637
Depends on: 648789
Depends on: 791670

Updated

5 years ago
No longer depends on: 791670
Also, dlbi (bug 539356) will likely improve the tab animations.
Depends on: 684861, 663395, 753559

Updated

5 years ago
No longer depends on: 753559

Updated

5 years ago
No longer depends on: 790840
Depends on: 792922

Updated

5 years ago
Depends on: 789573

Updated

5 years ago
Depends on: 738491

Updated

5 years ago
Blocks: 771444

Updated

5 years ago
blocking2.0: .x+ → ---
Component: Theme → General
Keywords: meta
Whiteboard: [softblocker][Snappy:P1] → [Snappy:P1]

Updated

5 years ago
Duplicate of this bug: 709984

Updated

5 years ago
No longer depends on: 743069

Updated

5 years ago
No longer depends on: 791637

Updated

5 years ago
Depends on: 750871
Depends on: 906827

Updated

a year ago
Depends on: 1015756

Updated

a year ago
Depends on: 998279
You need to log in before you can comment on or make changes to this bug.