Closed Bug 863662 Opened 11 years ago Closed 11 years ago

Keyboard takes 300-350ms to switch modes (upper/lower/numbers/symbols/...) on unagi

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 875963

People

(Reporter: jld, Assigned: janjongboom)

References

Details

(Keywords: perf, Whiteboard: [c= p= s=2013.12.06 u=])

Attachments

(1 obsolete file)

Like it says in the summary, the keyboard takes long enough (300-350ms on unagi) to switch between modes that it's noticeable and kind of distracting (and probably more so for someone who's faster at phone-typing than I am).

I notice that we're spending nearly 100ms on a sequence of reads of offsetLeft properties that force reflow.  I think we might be alternating between adding/changing elements and forcing reflow, and I wonder if we might be able to avoid that.

This profile might be helpful: https://people.mozilla.com/~bgirard/cleopatra/#report=423cef856b74c57c5ebbadf27fbf4e8e3125b5c6
I noticed the delay of keyboard in gaia-ui-tests automation execution time, too.
I didn't raise it, but I did think this is kind of slow.
Since it's a performace issue, let's try mark it as tef? :P
blocking-b2g: --- → tef?
Depends on: 863671
WE should not block on this one at this stage
blocking-b2g: tef? → ---
Whiteboard: [tef-triage]
Whiteboard: [tef-triage] → c=
Keywords: perf
Whiteboard: c= → c= ,
Assignee: nobody → janjongboom
Attached file Part 1: Optimize keyboard renderer (obsolete) —
Here are some optimizations for the renderer, that bring back the blocking cost of rendering the keyboard from ~100ms to ~40ms (on device).
Attachment #798843 - Flags: review?(rlu)
Oh, it's pretty easy to see the difference if you have two phones (the video I made of it is 300 MB so can't really share it...)
Jan,

Thanks for the patch.
I still need to find some time to review this in detail, but before that, could you help share how you measure the performance gain, is it by profiling as Comment 0?

Thanks.
No, using poor man's profiling because B2G desktop is broken on mc. Measuring the time the event loop blocks when rendering the keyboard.
Comment on attachment 798843 [details] [review]
Part 1: Optimize keyboard renderer

I don't really like to go back to using innerHTML while we have refined that to using DOM manipulation.

1. Can we consider either of the following ways to improve rendering?
   Cache each layout in a panel, like symbol panel and the default layout panel, and then do show/hide panel when we switch mode.

What do you think?
Attachment #798843 - Flags: review?(rlu) → feedback-
Even if we cache it, initial render time with DOM manipulation is 40 ms. (blocking code) to just generate elements. So we'll still need to do something about that.
Btw, putting the key elements in panels and hide them if not needed is good. Shaves 10 ms. off of restoring from cache.
Status: NEW → ASSIGNED
Whiteboard: c= , → [c= p= s= u=]
Assignee: janjongboom → sergi.mansilla
Assignee: sergi.mansilla → janjongboom
Attachment #798843 - Attachment is obsolete: true
See the attachment in bug 875963
Target Milestone: --- → 1.2 C3(Oct25)
Attachment mime type: text/plain → text/x-github-pull-request
Jan, any update on this issue?
Flags: needinfo?(janjongboom)
Yeah, the work for this is in bug 875963.
Depends on: 875963
Flags: needinfo?(janjongboom)
Target Milestone: 1.2 C3(Oct25) → ---
Jan, if bug 875963 will handle improving this delay please close this one as a DUPLICATE of it.
Flags: needinfo?(janjongboom)
Priority: -- → P2
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: needinfo?(janjongboom)
Resolution: --- → DUPLICATE
Whiteboard: [c= p= s= u=] → [c= p= s=2013.12.06 u=]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: