Thanks for the report, sorry that this behavior has regressed for you.
To input (bokan@) and WebView (torne@) bug triages queues.  Any ideas?

Could you update your simple apk? so we can try to reproduce it.

Any app with a webview will do. For instance, I can reproduce the problem using the AOSP app "Browser2" as found in:

https://android.googlesource.com/platform/packages/apps/Browser2/+/android-7.1.2_r33

The app does not have pinch zoom enabled, but you can easily enable it by adding these lines after:

https://android.googlesource.com/platform/packages/apps/Browser2/+/android-7.1.2_r33/src/org/chromium/webview_shell/WebViewBrowserActivity.java#385

    settings.setBuiltInZoomControls(true);
    settings.setDisplayZoomControls(false);

Note that pinch-zoom is not necessary to trigger the problem. Some websites present rendering problems right away. E.g. http://www.tomshardware.com , using any of the links in the latest news section result in rendering problems (see attached screenshot). This does not require to modify the AOSP Browser2 app as suggested above.

For your convenience, I've attached the Browser2 APK (with pinch-zoom enabled).

Deleted: webview-shell-chrome-61-2.png 475 KB

	webview-shell-chrome-61-2.png 475 KB View Download

Deleted: Browser2.apk 31.4 KB

Browser2.apk 31.4 KB Download

Thank you for providing more feedback. Adding requester "michaelbai@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

I were thinking it only happened when settings.setBuiltInZoomControls(true), are you able to reproduce this issue on other device?

Initially I thought it was related to pinch-zoom. But then I found out that there were rendering problems on various sites (see below), without even having pinch-zoom enabled.

In both cases, the problem looks similar, with rendering of (what looks like) garbage/dirty graphics buffers.

The problem occurs on a Baytrail platform with Celeron N2930 CPU. On another platform, Atom D525 (GMA3150), running the same software, the problem does not occur.

Example of web sites (with screenshot):
- https://www.ryanair.com/ie/en/
- https://www.ebay.ie

Deleted: webview-shell-chrome-61-ryanair.png 267 KB

	webview-shell-chrome-61-ryanair.png 267 KB View Download

Deleted: webview-shell-chrome-61-ebay.png 356 KB

	webview-shell-chrome-61-ebay.png 356 KB View Download

what android device has that gpu?

http://www.flytech.com/product/30/K940

from bugreport, looks like it's a fork of android x86 which itself is not an officially supported thing. I guess desktop-class gpu drivers on linux is worse than on drivers on android. You should really be talking to whoever provided gpu drivers here, and see if they can fix their driver issues instead

Yeah, looks like this device is distributing the Google-branded webview without any mechanism to update it (and quite possibly without any permission to do so) as well.

The fact is that the problem only starts to appear on Chrome/61. Everything works fine in Chrome/60 running on exactly the same OS. Why do you assume the problem is in the gpu driver?

Also, the Chrome browser app does not have rendering problems (again, running on the exact same OS). It only affects the WebView component, provided by the very same Chrome APK. If it was a GPU driver problem, it would logically affect both the WebView and the Chrome browser app.

> Why do you assume the problem is in the gpu driver?

It works fine regular android devices we officially support.

General contract is chrome codes to the EGL/GLES specs. Then when supported drivers exhibit problems, we have to blacklist drivers for find workarounds, which takes a lot of time; and at the same time, we tell the vendor the driver bugs we find. But this is not a device we official support, so you can only rely on that second step.

> If it was a GPU driver problem, it would logically affect both the WebView and the Chrome browser app.

Webview uses gpu driver differently compared to chrome.

Could you at least point int the sources to what has changed between version 60 and 61 of the WebView regarding its use of the GPU driver, which can explain the breakage?

I don't know what changed. But chromium is open source. You can get the changelog between versions by putting in the version numbers here: https://omahaproxy.appspot.com/

There are hundreds of changes each day, so it's going to be a lot of them to look through.

Right. Thanks for the help.

Can you also point in the source code where the webview and the browser makes different usage of the GPU driver?

There's too many things to point out. Plus if you were thinking of just limiting to changes in those files, then that doesn't work. It could be a change that affects both chrome and webview, but the interaction between that change and webview-only code that causes problems.

Well, I was just trying to get some support on an observed regression. But it doesn't sound like I will get any.

We understand, but it's extremely difficult to guess what possible change might have occurred - tracking down issues like this when we don't have the hardware to test on is practically impossible (normally we would start by bisecting the versions inbetween to see which change introduced the issue). The WebView team are only a small part of Chromium and many changes occur which we don't know anything about.

If you can get a build environment set up, get the device to load a webview you've built, and bisect it down to a specific change then we might be able to suggest some kind of workaround, or add a blacklist entry, but there's not a lot we can do otherwise. This device isn't something we can realistically support: it doesn't appear to share any graphics hardware or drivers with any other device we know anything about or have access to, and it doesn't receive WebView updates from us in any case.

There is unfortunately a long history of drivers having bugs that primarily manifest when using WebView, because WebView does things most other android apps don't (e.g. sharing stuff across threads), and can't avoid doing those things because of platform requirements.

Also, since that device doesn't ship with the Play Store preinstalled, it also shouldn't be using the Google webview at all; that's only distributed alongside the store. I have no idea how the device is configured with regards to webview or why, but it's expected to be the device manufacturer's responsibility to handle updating WebView on devices that don't come with the Play Store - we have no control over it.

I'm going to close this for now since there's not really any action we can take here right now; if you can track down the particular change we can take a look.

This is indeed not a consumer device. I'm building the Android firmware (out of Android-x86) and I can build the webview as well. I could try to locate the offending change, however chromium is not a single repository and I'm not sure how you'd bisect. Is there some online documentation about bisecting chromium project?

src/ is the top level repo, and contain pinned versions of all the other repos. So you can bisect src/, and just run gclient sync each step to sync all the other repos to match src/.

I've always found gclient sync to update me to ToT...might depend on your configuration. To checkout and build a certain rev (e.g. abcdef) I use:

gclient sync --revision src@abcdef

Isn't the same as:

    git checkout abcdef
    gclient sync

or is there a risk the end result will be different? I started bisecting (obviously a slow process), but I'm not providing any revision to gclient.

as long as after the gclient sync, the `git log -1` is the hash you checked out it should be fine.

Bisecting ended up pointing to this commit:
https://chromium.googlesource.com/chromium/src/+/63fbdcc12a7ef762e0652c972986fe74835ba00e

I've recompiled the WebView @ 62.0.3202.73 and tested it. While the rendering problem is quite mitigated, I'm still getting rendering problems after a few pinch-zoom gestures on Google's search page.

Then I tried to revert this commit, disabling the GPU scheduler by default, and the I couldn't reproduce the problem anymore:
https://chromium.googlesource.com/chromium/src/+/63fbdcc12a7ef762e0652c972986fe74835ba00e

That's something I could live with (patching the WebView for my hardware). However it seems that a recent commit has removed the ability to disable the GPU scheduler (not 100% sure, but that's how I interpret the commit):
https://chromium.googlesource.com/chromium/src/+/adddad7c3b085ef80fb99be1d11a4f0828677a0d

That seems to make the situation hopeless if I want to keep the webview up to date on my hardware.

I'm happy to provide any needed information about the hardware and/or software. I'm using Android-x86, everything is open source anyway.

+sunnyps: summary is that enabling gpu scheduler broke on some unsupported set up in webview: running android-x86 (non-google open source project to port android to desktop) presumably using desktop class drivers on intel

I guess I don't really know what gpu scheduler does? re-order some stuff running on the gpu?

Yeah, the gpu scheduler reorders command buffer work in the gpu process. It's possible there were preexisting synchronization bugs that are revealed by the reordering. I'd check if EGL fences work properly on this platform. We rely on those heavily when switching between the gpu process shared context and the hwui context.

Can you get tracing to work? Connect a device with usb debugging turned on to your PC. Open chrome://inspect?tracing on your PC, select the webview instance which exhibits the bug, record a trace when the bug shows with the rendering categories.

I'll try to get the trace tomorrow. Does it matter which version I'm using? With 61, it's trivial to reproduce. Versions 62 and 63 behave better, but the problem is still there, through harder to reproduce, so it might be more difficult to get the trace.

Probably not, we can look at the trace from 61 first. adb logcat output will also be helpful.

There's the full adb bug report in the initial comment.

Found something interesting:

10-24 12:10:22.862  2546  2636 E chromium: [ERROR:gl_context_egl.cc(202)] eglSwapInterval failed with error EGL_SUCCESS

This sounds similar to issue 724999 which also affects android x86.

PID=2546 is not the process hosting the webview with rendering problem. This is another app that is using/embedding crosswalk/23 (based on Chrome/53). The app with rendering problem is com.lincor.browser, PID=5470.

Here's the trace. I used Chrome Browser (61.0.3163.98) as WebView provider and the webview shell app from AOSP. I started the app on Google search page and did a single pinch-zoom gesture while recoding the trace. I also attached a screenshot of the screen after the operation. Finally, I attached the current logcat output; the process hosting the webview is PID=2571.

Deleted: trace.json.bz2 124 KB

trace.json.bz2 124 KB Download

Deleted: trace-logcat.log.bz2 55.4 KB

trace-logcat.log.bz2 55.4 KB Download

Deleted: trace-end-result.png 55.7 KB

	trace-end-result.png 55.7 KB View Download