[B2G] [Performance]: Contacts Scroll FPS

RESOLVED INVALID

Status

Firefox OS
Gaia::Contacts
P1
normal
RESOLVED INVALID
5 years ago
5 years ago

People

(Reporter: Sandip Kamat, Unassigned)

Tracking

({perf})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [c=handeye p= s=2013.09.20 u=])

(Reporter)

Description

5 years ago
Based on partner expectations, Minimum Expected Benchmark for Contacts App Scrolling is 57 FPS. The bug is to track the user story for both (1.0.1, 1.1) releases. 1.1 should cause no regression from 1.0.1.
Whiteboard: PERF → PERF [UCID:Perf14, FT:Perf, KOI:P1]
Blocks: 897222
Do we have the measure with the high speed camera right now?

Comment 2

5 years ago
(In reply to Francisco Jordano [:arcturus] from comment #1)
> Do we have the measure with the high speed camera right now?

We have Eideticker:

  http://eideticker.wrla.ch/b2g/#/b2g-inari/b2g-contacts-scrolling/fps

Although it has not been updated since June 6.  I think it also is based off of v1-train/b2g18 at the moment.  I believe there are plans to start monitoring master/m-c

William Lachance built eideticker and can probably provide a lot more information .
FWIW, the Eideticker camera measurement is not the same measure that our partner uses. But we should be able to use it to detect regressions.
That's awesome :)

Thanks folks!

Comment 5

5 years ago
(In reply to William Lachance (:wlach) from comment #3)
> FWIW, the Eideticker camera measurement is not the same measure that our
> partner uses. But we should be able to use it to detect regressions.

Yea, I think this story does need to define how this is measured.  We also have out fps overlay in the settings, but I doubt thats as accurate.

By the way, current gaia master scrolls at about 40fps according the overlay method.  I'll be interested to see what eideticker shows when its up and running on master as well.

Updated

5 years ago
Keywords: perf

Updated

5 years ago
Whiteboard: PERF [UCID:Perf14, FT:Perf, KOI:P1] → PERF [UCID:Perf14, FT:Perf, KOI:P1] [c= u=1.1]

Updated

5 years ago
QA Contact: gmealer

Updated

5 years ago
Priority: -- → P1

Updated

5 years ago
Summary: [B2G] [Performance User Story]: Contacts Scroll FPS → [B2G] [Performance]: Contacts Scroll FPS
Whiteboard: PERF [UCID:Perf14, FT:Perf, KOI:P1] [c= u=1.1] → [c=handeye p= s= u=1.2]
Target Milestone: 1.1 QE6 → ---

Updated

5 years ago
Whiteboard: [c=handeye p= s= u=1.2] → [c=handeye p= s= u=]
(In reply to Ben Kelly [:bkelly] from comment #5)
> (In reply to William Lachance (:wlach) from comment #3)
> > FWIW, the Eideticker camera measurement is not the same measure that our
> > partner uses. But we should be able to use it to detect regressions.
> 
> Yea, I think this story does need to define how this is measured.  We also
> have out fps overlay in the settings, but I doubt thats as accurate.
> 

I agree with you that we should use the same measure and it would be good to double check what partners use. But about the fps counter it comes from Gecko and if it is not accurate we need to fix it because that's be best (only) thing we have :)

 I have been told that the way it is written can cost us some frames when it is displayed though.
(Reporter)

Updated

5 years ago
Blocks: 915064
(Reporter)

Updated

5 years ago
No longer blocks: 915064
Closing the old user story bugs in favor of the bugs that show the regressions based on partner testing, bug 915064 and bug 915068.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID

Updated

5 years ago
Whiteboard: [c=handeye p= s= u=] → [c=handeye p= s=2013.09.20 u=]
You need to log in before you can comment on or make changes to this bug.