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?
Taking the build given in comment 0 gives: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2396696f1631&tochange=bd474ff6f86c
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?
Bug 575056 & Bug 572488 added Opaqueness combined with -moz-linear-gradient Usage. So isn't this rather a Core Perf Bug?
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 , 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. : 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+.
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.
Is it all Linux machines, or only older ones? If all Linux, please remove [softblocker] so we can reconsider that verdict.
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.
Summary: Tab animation perf issue → Tab animation perf issues
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.
blocking2.0: .x+ → ---
Component: Theme → General
Whiteboard: [softblocker][Snappy:P1] → [Snappy:P1]
Is this meta bug still relevant?
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.
You need to log in before you can comment on or make changes to this bug.