[meta] measure performance for Panorama

RESOLVED INVALID

Status

defect
P3
normal
RESOLVED INVALID
9 years ago
3 years ago

People

(Reporter: jbecerra, Unassigned)

Tracking

({perf})

Trunk
Firefox 4.0
x86
All
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
The performance story for Panorama isn't well defined. At the moment we mostly rely on anecdotal evidence to gauge performance of the feature. Depending on the hardware, number of tabs open, etc... Panorama interaction can feel very sluggish or ok.

Can we start tracking performance numbers using any test suites available? Last week's Mozmill demo showed a starting point, but we should have something setup soon so we get numbers for comparison.
(Reporter)

Updated

9 years ago
blocking2.0: --- → ?
Priority: -- → P3
I agree that this is a good thing to track, but I'm not sure I'd block on it without tight criteria. Let me think about it some more.

Ian/Aza: do you have any criteria that you'd been tracking to for responsiveness/performance?

Comment 2

9 years ago
I'd boil down it into two categories:

(1) Interaction speed:
  + Animation FPS (the zoom animations, dropping a tab into a group, opening a stacked group)
(2) Systematic
  + FPS of the above over time

On implementation side, my plan is currently to do some internal measuring of the animations and drags to get a sense of the FPS. If it is to slow, then we'll downgrade to less intensive animations (think bounding boxes, or other forms of being clever).

Updated

9 years ago
Blocks: 598154
Target Milestone: --- → Firefox 4.0
Start up speed (loading the Panorama UI the first time in a session), is another area we should track.

Comment 4

9 years ago
Yeah, the first-click experience is what I notice most desperately. I can't reproduce it right now, but I've had it freeze Firefox for 20+ seconds.

Comment 5

9 years ago
From Ian Gilman on removing shadows for zoom animations:

I'm pretty sure we already remove shadows for the zoom animation. The problem with removing shadows for dragging is that it gives exactly the wrong visual impression; the shadow should actually get bigger to imply that the object is further away from the background.

Even so, maybe there are clever ways we can lose the shadows. Perhaps tabs lose their shadows when they get grouped (dragging and resizing groups is a lot more work than single tabs)? Perhaps low-end machines don't get shadows?

I wonder if it makes a difference whether there are shadows present at all on the page, or if it's just the element that's animating?

Comment 6

9 years ago
(In reply to comment #4)
> Yeah, the first-click experience is what I notice most desperately. I can't
> reproduce it right now, but I've had it freeze Firefox for 20+ seconds.

I believe this is bug 589076, assigned to me. I investigated this Friday, and it looks like it's caused by TabItem.arrange(), which is called for every tab added. It in turn calls setBounds() on every tab in the arrangement, which touches a ton of CSS. I'm already working on a simple solution that has sped it up considerably (arranging only once at the end of each GroupItem initialization).
Status: NEW → ASSIGNED
Status: ASSIGNED → NEW
(In reply to comment #6)
> (In reply to comment #4)
> > Yeah, the first-click experience is what I notice most desperately. I can't
> > reproduce it right now, but I've had it freeze Firefox for 20+ seconds.
> 
> I believe this is bug 589076, assigned to me. I investigated this Friday, and
> it looks like it's caused by TabItem.arrange(), which is called for every tab
> added. It in turn calls setBounds() on every tab in the arrangement, which
> touches a ton of CSS. I'm already working on a simple solution that has sped it
> up considerably (arranging only once at the end of each GroupItem
> initialization).

Note, this is quite similar in intent (though perhaps orthogonal) to my optimizations to the arrange and storing "columns" values for groups: bugs 602777 and 591711.
Keywords: perf

Updated

9 years ago
Depends on: 598435

Updated

9 years ago
Depends on: 602432

Updated

9 years ago
Blocks: 604213

Comment 8

9 years ago
Note that we are now tracking all performance related stuff in bug 604213.
No longer depends on: 598435, 602432
Not blocking on this meta bug. Please nominate the individual pieces of work to  block, where needed.
blocking2.0: ? → ---

Comment 10

8 years ago
bugspam (moving b9 to b10)
Blocks: 608028

Comment 11

8 years ago
bugspam (removing b9)
No longer blocks: 598154
This is more of a task than a bug, and for a meta bug, it has a suspiciously nonexistent collection of dependencies.

Should we close this? Punt to the future?
Blocks: 627096
No longer blocks: 608028

Comment 13

8 years ago
(In reply to comment #12)
> This is more of a task than a bug, and for a meta bug, it has a suspiciously
> nonexistent collection of dependencies.
> 
> Should we close this? Punt to the future?

We should just close it.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.