on-screen keyboard makes system very busy |
||||||||||||||||
Issue descriptionChrome 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.
,
Aug 2 2016
Hi wuyingbing, can you add more detail (traces, references to code, logs, etc) to your question in #1?
,
Aug 2 2016
In mobile week. Didn't bring ChromeOS devices. Will reply in next week.
,
Aug 5 2016
,
Aug 17 2016
Hi djkurtz, I can't repro in clapper.
,
Aug 17 2016
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
,
Aug 17 2016
@#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.
,
Aug 17 2016
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.
,
Aug 17 2016
#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?
,
Aug 18 2016
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.
,
Aug 18 2016
"Show the keyboard cost lot of CPU. When it's done." Sorry, I don't understand. Can you please clarify what does this mean?
,
Aug 18 2016
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.
,
Aug 18 2016
,
Aug 19 2016
Hi danaki&abarth, Please ignore the previous request. I may find the root cause.
,
Aug 19 2016
,
Aug 23 2016
The following revision refers to this bug: https://chrome-internal.googlesource.com/chromeos/overlays/chromeos-overlay/+/42ca14ab856acc8bc3a40af742e574120ada5467 commit 42ca14ab856acc8bc3a40af742e574120ada5467 Author: Shu Chen <shuchen@google.com> Date: Fri Aug 19 09:38:45 2016
,
Aug 24 2016
The fix is included since 8735.0.0.
,
Aug 29 2016
,
Oct 7 2016
,
Nov 19 2016
,
Jan 21 2017
,
Feb 7 2017
Moving old issues out of Internal>Graphics to delete this obsolete component ( crbug.com/685425 for details)
,
Mar 4 2017
,
Apr 17 2017
,
May 9 2017
Verified in 59.0.3071.33, 9460.18.0 (Official Build) dev-channel veyron_minnie. |
||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||
Comment 1 by wuyingbing@chromium.org
, Jul 27 2016