Chrome_InProcGp thread hanging 200+ms only in WebView
Reported by
b...@lucidchart.com,
Aug 23 2017
|
||||||||||
Issue descriptionSteps to reproduce the problem: 1. Load a WebView in an Android app 2. Navigate to www.lucidchart.com/documents and log in/sign up 3. Create a new Lucidchart document from one of the templates 4. Navigate to www.lucidchart.com/documents/tabletNative/<docId> (automatically handled by the .apk attached when you try to open a document) 5. Touch & drag to pan around the document Example code for the webview app: WebView webView = (WebView) findViewById(R.id.webView); webView.setWebViewClient(new WebViewClient()); WebSettings settings = webView.getSettings(); settings.setJavaScriptEnabled(true); WebView.setWebContentsDebuggingEnabled(true); webView.setWebViewClient(new WebViewClient() { public boolean shouldOverrideUrlLoading(WebView view, String url){ url = url.replace("/viewer/", "/tabletNative/"); view.loadUrl(url); return false; } }); webView.loadUrl("https://www.lucidchart.com/documents"); What is the expected behavior? It should pan at 60FPS like it does in the Chrome browser What went wrong? The view will freeze for hundreds of milliseconds several times shortly after you start dragging to pan around. There will be many fast frames, but some individual frames will be hundreds of milliseconds long. systrace output shows the Chrome_InProcGp thread locking up a CPU thread for the duration of the lock. I've attached systrace output from a Pixel C, both from the Chrome browser and from the attached .apk. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 59.0.3071.125 Channel: stable OS Version: 7.1.2 Flash Version: systrace appears to show the GPU itself mostly idle; not sure why this GPU-related CPU thread is hogging all the resources, and only in the WebView.
,
Aug 24 2017
prefer chrome trace over systrace: https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs#TOC-Capture-a-trace-from-Chrome-on-Android-with-DevTools- and if you take systrace, include the "webview" category for webview Webview has two "gpu" threads, android's "RenderThread" and chrome's "Chrome_InProcGp[u]". It *looks* like in this case, renderthread is blocked and while the chrome thread is running. They do use a lock to share egl image tracking state, but 180ms seems like a ridiculously long time for that. I think chrome trace with at least the default categories will at least identify what those threads threads are doing/waiting on
,
Aug 24 2017
and for kbr, that lock is in mailbox_manager_sync
,
Aug 24 2017
Please let me know if there's additional information you need me to provide. I'm not sure how to run chrome://tracing on a connected device's webview though.
,
Aug 24 2017
The instructions for Chrome that Bo linked to also work for webview if you've enabled webview debugging in your app.
,
Aug 24 2017
Yeah, webview article is two links down compared to chrome: https://developers.google.com/web/tools/chrome-devtools/remote-debugging/webviews
,
Aug 25 2017
Thanks, not sure how I missed it. I'll post some tracing output soon.
,
Oct 3 2017
Ben, any update?
,
Oct 4 2017
Sorry, this fell off my backlog for a little while. I'll get something up for you this week.
,
Oct 4 2017
Thank you for providing more feedback. Adding requester "ntfschr@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 4 2017
Adding needs-feedback for the trace.
,
Oct 10 2017
I've attached a trace from Chrome and a WebView on a Nexus 9. In the course of the several seconds recorded in the WebView, you'll see about 3 100-150ms pauses in the InProcGpu thread.
,
Oct 10 2017
Thank you for providing more feedback. Adding requester "ntfschr@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 11 2017
Are the original systraces from a nexus 9 as well? That explains a lot of things.. Nvidia driver does an cpu copy for every texture in nexus 9, and this only happens in webview. Apparently newer drivers fixed this, but nexus 9 is too old to get the update I think: https://bugs.chromium.org/p/chromium/issues/detail?id=492315#c74. And looking at the trace, that copy does indeed happen while that global lock is held. Also nexus 9 was just a really slow device. It has 4 cores, but looking at that systrace, it can maybe only keep 2 of them running at the same time. The trace chrome shows there is non-stop javascript running on the blink main thread, which also competes with those 2 cores. At this point, we really don't care that much about this, given the small population of nexus 9 and old nvidia devices in general, and given newer drivers have this fixed already. Sorry
,
Oct 11 2017
No, the worst original traces were from a brand-new Jamboard. The effect there is so horrendous that it renders our application unusable. But we don't have a Jamboard in dev mode in our offices here so I had to repro on another device we had on hand (Nexus 9). The other original traces were from a Pixel C, which also showed the effect but to a lesser degree (100ms pauses instead of 250ms+ pauses).
,
Oct 11 2017
Note: Original traces posted here were only from the Pixel C; not sure what happened to the Jamboard traces, but they probably just put us over the attachment size limit, and we thought you might care about the Pixel C more than the Jamboard :-D |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by kbr@chromium.org
, Aug 24 2017Components: Blink>WebGL Mobile>WebView
Owner: boliu@chromium.org