598394 - [meta] measure performance for Panorama

Status: RESOLVED INVALID

(Firefox Graveyard :: Panorama, defect, P3)

Description

[juan becerra [:juanb]]

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.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

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

[Aza Raskin [:aza]]

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).

Comment 3

[Ian Gilman [:iangilman]]

Start up speed (loading the Panorama UI the first time in a session), is another area we should track.

Comment 4

[Benjamin Smedberg]

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

[Aza Raskin [:aza]]

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

[Sean Dunn]

(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).

Comment 7

[Michael Yoshitaka Erlewine [:mitcho]]

(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.

Comment 8

[Aza Raskin [:aza]]

Note that we are now tracking all performance related stuff in bug 604213.

Comment 9

[Dietrich Ayala (:dietrich)]

Not blocking on this meta bug. Please nominate the individual pieces of work to  block, where needed.

Comment 10

[Kevin Hanes]

bugspam (moving b9 to b10)

Comment 11

[Kevin Hanes]

bugspam (removing b9)

Comment 12

[Michael Yoshitaka Erlewine [:mitcho]]

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?

Comment 13

[Kevin Hanes]

(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.