New issue
Advanced search Search tips

Issue 615609 link

Starred by 2 users
Status: Fixed
Owner: ----
Closed: Aug 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

Android WebView composite time on WebGL canvas is 10x slower than Chrome browser

Reported by mich...@activetheory.net, May 28 2016 
Steps to reproduce the problem:
1. Add WebGL canvas to HTML page and draw on it each frame
2. Profile the page with the Timeline inspector

What is the expected behavior?
WebView and Chrome browser should show the same times per frame.

What went wrong?
The WebView is showing ~7ms for "Composite Layers" when Chrome browser shows ~0.6ms.

The app hosting the WebView has no other views. These results are seen on a page with nothing other than a WebGL canvas in the body.

Did this work before? N/A 

Chrome version: 51.0.2704.36  Channel: n/a
OS Version: 6.0.99
Flash Version:
Screen Shot 2016-05-28 at 12.13.45 AM.png
27.0 KB View Download
Screen Shot 2016-05-28 at 12.15.50 AM.png
34.7 KB View Download

Comment 1 by mich...@activetheory.net, May 28 2016 

I've uploaded some files to test against.

URL where results can be observed: http://files.activetheorylab.net/crbug

I've attached the APK I'm experiencing issues with. It will load a WebView pointing to the URL above.
app-debug.apk
1.1 MB Download

Comment 2 by rsgav...@chromium.org, Jun 3 2016

Components: Mobile>WebView

Comment 3 by boliu@chromium.org, Jun 4 2016

Components: Internals>GPU>Scheduling
Webview is generally going to be slower than chrome, because
* webview has to do more work sharing textures across threads
* webview has all sorts of synchronous/blocking behavior not in chrome
* webview frame scheduling is only partially controlled by itself

but scheduling here *really* sucks here. looks like the problem is the main thread started hogging the gpu to preparing frame N+1 when frame N has not been swapped yet, then that swap is sleeping blocked for a long time

no easy solution though, probably could look into holding off main frame a bit
trace_crbug_615609.json
2.6 MB View Download

Comment 4 by boliu@chromium.org, Aug 15 2016 

this probably improved when we split off the compositor thread from the UI thread. Can you check again on webview m50 or later?

Comment 5 by gsennton@chromium.org, Aug 22 2016

Labels: Needs-Feedback

Comment 6 by mich...@activetheory.net, Aug 26 2016 

Thanks for the update -- this seems to be fixed on Android 7 WebView 53!

Comment 7 by boliu@chromium.org, Aug 26 2016

Status: Fixed (was: Unconfirmed)
►

Sign in to add a comment