Closed Bug 970193 Opened 10 years ago Closed 10 years ago

[Keyboard] The first switching time of third party keyboard spends ~1.6 seconds

Categories

(Firefox OS Graveyard :: Gaia::Keyboard, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:2.0+)

RESOLVED DUPLICATE of bug 970188
blocking-b2g 2.0+

People

(Reporter: whsu, Assigned: timdream)

References

Details

(Keywords: perf, Whiteboard: [FT:System-Platform], [3rd-party-keyboard][p=3][c=effect p= s= u=2.0])

Attachments

(2 files)

* Description:
  After we completed the keyboard performance measurement (Bug 946298), we found that first switching time of third party keyboard spends 550..6 centiseconds. We need to make a decision if we need to improve first switching time of third party keyboard.
  Attaching the result. (Keyboard_Switch_Time.png)

* Precondition:
  Install a third party keyboard and enable keyboard OOP

* Reproduction steps:
  1. Restart the Firefox OS device
  2. Go to "Settings" app to enable a third party keyboard
  3. Launch the Contacts app.
  4. Tap "+" icon to edit a new contact
  5. Tap name field

* Expected result:
  The first switching time is smooth and fast

* Actual result:
  The first switching time of third party keyboard spends 550..6 centiseconds

* Build info:( V1.4 )
  - Location: /pvt/mozilla.org/b2g_ril/hamachi-eng-mozilla-central-20140126040203-ril01.02.00.019.102.zip 
  - Build Id: 20140126004002 
  - Gaia: f382061fe95750d584a9078175c421a36892afc9 
  - Gecko: 3f1dd2a8e972
blocking-b2g: --- → 1.4?
Whiteboard: [FT:System-Platform], [3rd-party-keyboard]
Summary: [Keyboard][Performance][V1.4] The first switching time of third party keyboard spends 550..6 centiseconds. → [Keyboard][Performance][V1.4] The first switching time of third party keyboard spends 550.6 centiseconds.
This is a regression from enabling oop keyboard support.
Blocks: 942790
Keywords: perf, regression
William - What's the performance fallout here in terms of time? The bug is citing the mean time to execute the test in question, but it isn't clarifying what the performance regression is here.
Flags: needinfo?(whsu)
(In reply to Jason Smith [:jsmith] from comment #2)
> William - What's the performance fallout here in terms of time? The bug is
> citing the mean time to execute the test in question, but it isn't
> clarifying what the performance regression is here.

Oh wait, now I get it. What you are saying is that switching to a third-party keyboard takes 5.506 seconds, where as switching within the built-in keyboard & non-oop keyboard was 0.054 seconds & 0.06 seconds respectively. So this isn't a regression, but it'll be a blocker to ship third party keyboards, as 5.506 seconds to switch to a third party keyboard is way too long for a user to tolerate.
Flags: needinfo?(whsu)
Keywords: regression
Hi, Jason,

Yes. You got it!
Thanks. Have a nice day! :)
Whiteboard: [FT:System-Platform], [3rd-party-keyboard] → [c=effect p= s= u=] [FT:System-Platform], [3rd-party-keyboard]
Rudy, is this a bug in the new keyboard codebase or it's something in the input management?

It's unclear to me on that STR -- whether or not William have disabled the original keyboard on step 2 or not. Please confirm with him.
Flags: needinfo?(rlu)
I enable both 1)built-in English keyboard and 2) Demo keyboard on the step 2.
Flags: needinfo?(rlu)
Let me investigate.
Assignee: nobody → timdream
No longer blocks: 942790
Blocks: 964670
I am unable to reproduce the bug on Unagi, with keyboard oop turned on locally.

I am not sure if you are measuring the cold-launch speed of the Demo Keyboard. Also, if build-in keyboard is not disabled on step 2, demo keyboard should not be launched and switched to unless you tap the global key on step 5.

William, could you re-test and give out a more clear STR? Thank you very much!
Flags: needinfo?(whsu)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #8)
> I am unable to reproduce the bug on Unagi, with keyboard oop turned on
> locally.
> 
> I am not sure if you are measuring the cold-launch speed of the Demo
> Keyboard. Also, if build-in keyboard is not disabled on step 2, demo
> keyboard should not be launched and switched to unless you tap the global
> key on step 5.
> 
> William, could you re-test and give out a more clear STR? Thank you very
> much!

How exactly did you measure the performance here on Unagi? And how does that measurement methodology compare to William's approach in https://docs.google.com/a/mozilla.com/file/d/0B3SBjlVFSBc3bGdaMUExa0lZdFE/edit?
(In reply to Jason Smith [:jsmith] from comment #9)
> How exactly did you measure the performance here on Unagi? And how does that
> measurement methodology compare to William's approach in
> https://docs.google.com/a/mozilla.com/file/d/0B3SBjlVFSBc3bGdaMUExa0lZdFE/
> edit?

I simply try to switch between keyboards manually, w/ stop watch. 

If we need more accurate result, I guess we should try this bug with high speed camera but with the two-key test keyboard as the 3rd-party one, instead of the more complex demo-keyboard.
Hi, Jason,

Just want to say ~ "Thanks"
Thanks for spending your vacation time to follow this bug.
Have a nice vacation! :)

--------------------------------------------------------
Hi, Tim,

Okay. I will measure it later because I am working on the other tasks of functional teams.
Thanks.

--------------------------------------------------------
...Keep NeedInfo
3rd party keyboard will be disabled in v1.4 so that this one is not the blocker for v1.4. Will address this in v1.5 with 3rd party work.
blocking-b2g: 1.4? → 1.5?
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #10)
> (In reply to Jason Smith [:jsmith] from comment #9)
> > How exactly did you measure the performance here on Unagi? And how does that
> > measurement methodology compare to William's approach in
> > https://docs.google.com/a/mozilla.com/file/d/0B3SBjlVFSBc3bGdaMUExa0lZdFE/
> > edit?
> 
> I simply try to switch between keyboards manually, w/ stop watch. 
> 
> If we need more accurate result, I guess we should try this bug with high
> speed camera but with the two-key test keyboard as the 3rd-party one,
> instead of the more complex demo-keyboard.

Hi, Tim and all,

Thanks for your help.
Today, I looked into this case and tried to measure the cold launch performance of Gaia Test keyboard(Two keys).
But, an issue blocks my test.
 - Bug 958003: FxOS cannot pops up demo keyboard (in test_apps) after process manager kills it
I think your test steps & build should be different from mine since you can measure the cold launch time of Gaia Test keyboard.

Because of the blocking issue, I only can measure the switching time of Gaia Test keyboard.
Here are the test results. FYI.
01. 1.59 seconds			
02. 1.51 seconds
03. 1.50 seconds
04. 1.67 seconds
05. 1.79 seconds
06. 1.71 seconds
07. 1.54 seconds
08. 1.57 seconds
09. 1.79 seconds
10. 1.72 seconds
Average time: 1.639 seconds

Following are my test steps. FYI.
- Keyboard cold launch test
 Step 1: Restart the FxOS device
 Step 2: Launch the settings app
 Step 3: Enable Gaia Test Keyboard
 Step 4: Disable Built-in English keyboard
 Step 5: Launch the Contact app
 Step 6: Tap the "+" icon
 Step 7: Tap the name field
 Step 8: Wait for keyboard (Bug 958003 blocks my test)
 * Demo Video: NA

- Keyboard switching test (First-time switching)
 Step 1: Restart the FxOS device
 Step 2: Launch the settings app
 Step 3: Enable Gaia Test Keyboard
 Step 4: Launch the Contact app
 Step 5: Tap the "+" icon
 Step 6: Tap the name field
 Step 7: Wait for keyboard
 Step 8: Tap Globe key to switch keyboard
 * Demo Video: https://dc1.safesync.com/LMtzcYMp/KeyboardSwitching_20140224.wmv?a=m5tcR804SYo

It might cause by the different design. Demo keyboard(David)needs to load more settings than Gaia Test keyboard.
So, the switching time of Demo keyboard(David) and Gaia Test keyboard are different.
Any thought?
Thanks!
Flags: needinfo?(whsu)
After talking to William offline I think his measurement is accurate and we need to address this.
Summary: [Keyboard][Performance][V1.4] The first switching time of third party keyboard spends 550.6 centiseconds. → [Keyboard][Performance][V1.4] The first switching time of third party keyboard spends ~1.6 seconds.
Triage: keep 1.5? because we need to make sure we don't ship 1.5 (with keyboard oop enabled) with this bug.

The fix should be either ship keyboard refactor work (bug 956169) or address this bug in the current code base.
Summary: [Keyboard][Performance][V1.4] The first switching time of third party keyboard spends ~1.6 seconds. → [Keyboard] The first switching time of third party keyboard spends ~1.6 seconds
blocking-b2g: 1.5? → 1.5+
Priority: -- → P1
Whiteboard: [c=effect p= s= u=] [FT:System-Platform], [3rd-party-keyboard] → [c=effect p= s= u=1.5] [FT:System-Platform], [3rd-party-keyboard]
Whiteboard: [c=effect p= s= u=1.5] [FT:System-Platform], [3rd-party-keyboard] → [c=effect p= s= u=2.0] [FT:System-Platform], [3rd-party-keyboard]
Adding story points. I need to find a time to measure this.
Whiteboard: [c=effect p= s= u=2.0] [FT:System-Platform], [3rd-party-keyboard] → [FT:System-Platform], [3rd-party-keyboard][p=3]
Whiteboard: [FT:System-Platform], [3rd-party-keyboard][p=3] → [FT:System-Platform], [3rd-party-keyboard][p=3][c=effect p= s= u=2.0]
Status: NEW → ASSIGNED
William, we have cold launch measurement on bug 970188 for Open C. Since the code path of both action is quite similar, do you still want to measure this again or we should take it our of 2.0+?

Thanks!
Flags: needinfo?(whsu)
I think we still need to mark it as "V2.0+" bug.

As you mentioned, we have put a lot of effort on related bug.
So, I think if we mark bug 970188 as "RESOLVED", we also can mark this bug as "Duplicate" or "WONTFIX".
Because switching time of third party keyboard is equal to "Cold/relaunch launch time" plus "Keyboard dismissing time".

Thanks!
Flags: needinfo?(whsu)
Let's dup this issue then since the action to resolve this bug will be always equal to bug 970188.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.