New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 631404 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Closed: Aug 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug


Participants' hotlists:
Fixing-touch


Sign in to add a comment

on-screen keyboard makes system very busy

Project Member Reported by djkurtz@chromium.org, Jul 26 2016

Issue description

Chrome Version: 54.0.2800.2
Chrome OS Version: 8622.0.0
Chrome OS Platform: veyron_minnie (or any Chrome OS convertible)

Steps To Reproduce:
(1) Fold keyboard back for "presentation" mode: _\ :-)
(2) Tap somewhere in a text box (ie omnibox) to open onscreen keyboard
(3) Use top to monitor system load.

Expected Result:

No noticeable increase in system load.

Actual Result:

System load spikes to > 50% cpu usage.

How frequently does this problem reproduce? (Always, sometimes, hard to
reproduce?)

Always.

What is the impact to the user, and is there a workaround? If so, what is
it?

Possible system performance impact with onscreen keyboard displayed

Please provide any additional information below. Attach a screen shot or
log if possible.

$ top (w/ c option )

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                              
 1540 chronos   12  -8  346148 288816 270416 R  60.7  7.0   1:26.55 /opt/google/chrome/chrome --type=gpu-process --mojo-channel-token=E5C92556037115E70F5623F7039F82D1 --mojo-application-channel-token+ 
15991 chronos   20   0  387500  53696  26220 S  51.2  1.3   0:31.15 /opt/google/chrome/chrome --type=renderer --enable-logging --log-level=1 --use-gl=egl --vmodule=screen_locker=2,webui_screen_locker+ 
 1083 chronos   12  -8  663784 133236  53320 S  38.7  3.2   1:58.12 /opt/google/chrome/chrome --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=22.0.0.209-r1 --p+ 
12819 chronos   20   0  490432  69104  23260 S   3.3  1.7   0:21.62 /opt/google/chrome/chrome --type=renderer --enable-logging --log-level=1 --use-gl=egl --vmodule=screen_locker=2,webui_screen_locker+ 
12802 chronos   20   0  342684  43708  27188 S   2.6  1.1   0:03.50 /opt/google/chrome/chrome --type=renderer --enable-logging --log-level=1 --use-gl=egl --vmodule=screen_locker=2,webui_screen_locker+ 

Also see attached chrome://tracing trace.
 
trace_onscreen_keyboard_idle.json.gz
2.4 MB Download
Owner: shuchen@chromium.org
Hi shuchen,
I think OS keep to trigger focus/blur then trigger the onscreen keyboard show and hide.
Do you have any idea to fix it?

Hi wuyingbing, can you add more detail (traces, references to code, logs, etc) to your question in #1?
In mobile week.
Didn't bring ChromeOS devices. 
Will reply in next week.
Labels: Hotlist-Recent-Vk-Regressions
Hi djkurtz,
I can't repro in clapper.
1.pic.jpg
68.3 KB View Download
The platform information:
version 54.0.2826.0 canary (64-bit)
Platform 8705.0.0 (Official Build) canary-channel clapper
Firmware Google_Clapper.5216.199.7
Cc: danakj@chromium.org
Components: Internals>Graphics
@#5 -
I can still reproduce on elm 8695.0.0 / 54.0.2824.0.
Can you try on veyron_minnie?

The extension is causing some work load for the Chrome graphics stack that is consuming a lot of CPU.

(1) hit 'c' in top to show process args, so you can see which is renderer and which is gpu-process.
(2) Even if the CPU % isn't as high as on the arm devices, take a look at chrome://tracing and see how much work is generated by process "The empty window, Input View Keyboard" when the keyboard is displayed but otherwise idle.

I've attached a trace for elm.

trace_virtual_keyboard.json.gz
2.3 MB Download
Hi danakj,
I didn't has veyron_minnie.
Yes, the "Input View Keyboard" is the onscreen keyboard.
It compose of many keyboard buttons. So the performance is not good.
Do you feel stuck when you use the device.
When the keyboard is showed, then CPU% will go down.
#7 - sorry, I don't really understand what you mean.

Can you take a chrome trace on your clapper?

I think it might show that the virtual keyboard is very busy, even when nobody is touching any keys.  The question is, what is it doing?  Can we make it idle when on screen, but not actually handling any touch events?
I check the process  "The empty window, Input View Keyboard", when it's showed.
It doesn't has heavy cpu usage.
Show the keyboard cost lot of CPU.  When it's done.
I think it's fine.

trace_trace.json.gz
16.9 MB Download
"Show the keyboard cost lot of CPU.  When it's done."
Sorry, I don't understand.  Can you please clarify what does this mean?
Owner: abarth@chromium.org
Hi abarth,
Virtual keyboard has high cpu even it's idle. 
Let me give you brief view.
Virtual keyboard is rendered in a input view container. The title is ""The empty window, Input View Keyboard"
We listen all mouse events on the document of the window, and it can interactive with background JS, background JS interactive with NACL.

When show the VK, we didn't press any physical key or move mouse, but the CPU usage is still high. We found the VK window process executed "PageAnimator.serviceScriptAnimate" in every 20~ms.

Please check the attachment, I am zoom in the track page and took some screenshot. In this VK version, I remove the CSS file, remove and mouse event listener and remove the chrome.runtime.onMessage listener.

Even so clean version, it still call that function every 20~ms.
But if I replace VK with empty HTML, it didn't call.

I find you by searching the code in chromium code base:https://chromium.googlesource.com/chromium/blink/+blame/master/Source/core/page/PageAnimator.cpp

I am not sure why it call "PageAnimator.serviceScriptAnimate" in every 20~ms.
Could you give me some guide, what's "PageAnimator.serviceScriptAnimate" doing?
Which case usually "PageAnimator.serviceScriptAnimate" is called?

On literal meaning, it's about animation, but I already remove css file. I get puzzled.
I am not sure find the right person to handle the issue. if not you please help to route the right one, thanks.

Screenshot 2016-08-18 at 5.26.50 PM.png
10.7 KB View Download
Screenshot 2016-08-18 at 5.26.25 PM.png
28.8 KB View Download
Screenshot 2016-08-18 at 5.25.55 PM.png
11.5 KB View Download
trace_vk.json.gz
11.2 MB Download
Cc: rbyers@chromium.org
Owner: wuyingbing@chromium.org
Hi danaki&abarth,
Please ignore the previous request.
I may find the root cause.
Cc: shuchen@chromium.org
Status: Started (was: Available)
Project Member

Comment 16 by bugdroid1@chromium.org, Aug 23 2016

Status: Fixed (was: Started)
The fix is included since 8735.0.0.
Labels: VerifyIn-54
Labels: VerifyIn-55

Comment 20 by dchan@google.com, Nov 19 2016

Labels: VerifyIn-56

Comment 21 by dchan@google.com, Jan 21 2017

Labels: VerifyIn-57
Components: -Internals>Graphics Internals>GPU
Moving old issues out of Internal>Graphics to delete this obsolete component ( crbug.com/685425  for details)

Comment 23 by dchan@google.com, Mar 4 2017

Labels: VerifyIn-58

Comment 24 by dchan@google.com, Apr 17 2017

Labels: VerifyIn-59
Status: Verified (was: Fixed)
Verified in 59.0.3071.33, 9460.18.0 (Official Build) dev-channel veyron_minnie. 

Sign in to add a comment