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

RESOLVED DUPLICATE of bug 875963

Status

P2
normal
RESOLVED DUPLICATE of bug 875963
5 years ago
4 years ago

People

(Reporter: jld, Assigned: janjongboom)

Tracking

({perf})

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 obsolete attachment)

(Reporter)

Description

5 years ago
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=

Updated

5 years ago
Keywords: perf
Whiteboard: c= → c= ,
(Assignee)

Updated

5 years ago
Assignee: nobody → janjongboom
Created attachment 798843 [details] [review]
Part 1: Optimize keyboard renderer

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.

Updated

5 years ago
Status: NEW → ASSIGNED
Whiteboard: c= , → [c= p= s= u=]
(Assignee)

Updated

5 years ago
Assignee: janjongboom → sergi.mansilla
(Assignee)

Updated

5 years ago
Assignee: sergi.mansilla → janjongboom
(Assignee)

Updated

5 years ago
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

Comment 11

5 years ago
Jan, any update on this issue?
Flags: needinfo?(janjongboom)
Yeah, the work for this is in bug 875963.
Depends on: 875963
Flags: needinfo?(janjongboom)

Updated

5 years ago
Target Milestone: 1.2 C3(Oct25) → ---

Comment 13

5 years ago
Jan, if bug 875963 will handle improving this delay please close this one as a DUPLICATE of it.
Flags: needinfo?(janjongboom)
Priority: -- → P2
(Assignee)

Updated

5 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Flags: needinfo?(janjongboom)
Resolution: --- → DUPLICATE
Duplicate of bug: 875963

Updated

5 years ago
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.