@Kinoseed: Could you please provide sample URL or pwa with a canvas, which has transparent parts and a slider to test this issue from our end. 
Also please confirm device you are seeing this issue. Is this issue reproducible on any of the Pixel devices?

Thanks!

The video capture of the screen was done on Mi5X device.
Whether Pixel phones are affected or not, I can't say.

At the moment the issue is "patched" by scaling (the density) to device resolution, so I will need some time to set you up with an example.

I'll post the link when it's ready.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Over to the WebView team since this is likely related to the webview compositing path.

Directly load:
https://kinoseed.com/

!!! 
If you run it as PWA, the manifest will load: https://kinoseed.com/?pwa=1
which will force device-resolution scaling.
!!!

Loading the URL in Chrome renders fine.
Loading the URL ( https://kinoseed.com/ ) in WebView shows the problem.
(tested and confirmed with WebView - url-loading app from google-play)

Forgot to mention - in the newer code here the "mesh" is drawn on the background canvas, and the problem still persists in WebView.

Tested the issue on android and below are the observations

Steps to reproduce:
--------------------------
1. Launched chrome and navigated to https://kinoseed.com/
2. Now added it to homescreen, opened photo match app from apps section
3. Scrolled the page and observed some flickering [seen only twice when tried 10 times]

Chrome/webview version:
70.0.3538.110

OS:
Android 9.0 

Android device:
Pixel XL

@ kinoseed: Please check the above steps and let us know if we miss anything. Please provide screencast of the issue. This would help in identifying the issue.

Thanks!

Running PWA by Chrome will not (should not) produce the issue.

The problem shows (along with noticeable performance drop), when the page is loaded in a WebView started by an app (the "System WebView"?).

To reproduce the problem, either create an app which loads the URL in a WebView, or load the URL in a WebView-test app. 

Here is how to reproduce it using a webview-test app from the google play:

Steps to reproduce:
--------------------------
1. Download and run: 
https://play.google.com/store/apps/details?id=info.android1.webview

2. Press "OK" to clear the intro-messages, and long-press on screen to open the options.
3. Press "settings" from the menu, enter https://kinoseed.com/ as URL, press "save", and device's "back button"
4. The page should now show the app. Press ☯, and move the sliders.


Screencast was included here: https://issuetracker.google.com/issues/119488399
(the file is bigger than 10Mb, so I can't attach it here)

apologies, if I was not clear enough about the issue with the initial post.  

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

It seems there are 2 problems:

 1. There are 2 squares with criss-cross patterns. The criss-cross lines flicker between sharp and fuzzy on WebView, *only* while the slider menu is moving.
 2. The slider menu has choppy movement on WebView, and is not as smooth as on Chrome.

Would it be reasonable to chalk both of these up to performance issues? WebView has graphics performance limitations, as it needs to integrate into the View hierarchy. boliu@ and tobiasjs@ does this seem plausible?

kinoseed@ have I overlooked any concerns?

As per c#11 adding Needs-Feedback label. @kinoseed: Could you please respond to c#11.

Thanks!

 @ntfschr what you are observing also seems to hold for the rendered text in the canvas as well.

The issue is also observed when there's css animation (in this case then you open/close the app's menu on the left).

I don't know if this is a result of imposed performance limitation, but I didn't notice rendering resolution changes in other elements, which don't have alpha and composed/placed on other elements (maybe it just was not evident in my case).

Looks like you're also the one who posted https://www.reddit.com/r/androiddev/comments/9vxjcj/help_webview_performance_rendering_problems/?utm_source=reddit-android

A bit of context: although much of the same code is used to render your site in Chrome, PWAs, and in WebView, that's not the end of the story. Chrome and Custom Tabs don't need to draw into the View Hierarchy; WebView is a View, and therefore it has this extra restriction. This requires an extra copy (and I believe other extra work), which can affect performance. So it's not as simple as "native vs. web" (which I believe you've already caught onto, based on the thread). boliu@ and tobiasjs@ understand the technical details far better than I do.

That said, I'm just guessing your issue is performance based. We could probably confirm this by firing up a trace, although I'm not entirely sure what to look for.

@ntfschr , yes indeed, I was the one who posted it on reddit.

Since filing the issue, I tried to replace WebView with GeckoView.
The performance difference is staggering.

The size of the app got significantly larger (due to the embedded lib), but it still loads the same code from the server in a View (and as you can see from code of the page, it is not wasm).

the latest version with GeckoView for comparison:
https://play.google.com/store/apps/details?id=com.kinoseed.matchcolor

GeckoView is not integrated with the view hierarchy (despite the name) - it renders to a texture that is drawn into a SurfaceView, which is the same rendering technique used by Chrome. This does not allow various view features like synchronous scrolling to function correctly (but Chrome doesn't need them). It's quite likely your app doesn't need them either, but WebView has to provide them for compatibility with the many apps which do (and to behave the same as the old webview implementation).

It's unfortunate but there is currently no way for us to avoid the performance overhead of rendering in the way we do.

Someone with graphics expertise might still be able to see something interesting in a trace from the repro case in #9

Bo and I were able to repro on google/bullhead/bullhead:6.0.1/MMB31D/3382996:userdebug/dev-keys (72.0.3626.14), but couldn't repro on all devices.

With webview, developers can also do things that inadvertently hurt performance. In your report in the other issue tracker, this line in particular can only hurt webview performance:
view.setLayerType(View.LAYER_TYPE_HARDWARE, null);

Performance between webview and chrome isn't wildly different, at least on a nexus 5x, which is what I would expect. Chrome is always going to perform better than webview though due to what torne said.

The rendering artifact though I have no explanation. I could only get it to show up (or I could only see it) on a nexus 5x, but not nexus 5 or pixel 2. The artifact shows up in static canvas (TextureLayer), so it's not due to raster. So it's probably has something to do with compositing instead, like maybe it has some different filter applied when there are animations. Also it's webview-only and does not appear to affect chrome. Pretty odd..

Thanks @boliu and @torne.

I tried everything I can think of to get rid of the "rendering artifacts", and in the issue tracker report was my last attempt (where I also used "view.setLayerType(View.LAYER_TYPE_HARDWARE, null);"), but with or without it on my device, the artifacts showed.

ps. It is regrettable that WebView can't match Chrome's performance.

Similar problem is observed when scrolling images (when choosing an image to load), even from the PWA.

I'm not sure if it will be visible on the screen-captured video (I can see it here only when I playback it on the phone at full screen), but there is serious "blinking problem", when scrolled. 

Deleted: Screenrecorder-2019-01-05-01-02-47-977.mp4 8.8 MB

	Screenrecorder-2019-01-05-01-02-47-977.mp4 8.8 MB View Download

Deleted: cat_t.jpg 1.1 MB

	cat_t.jpg 1.1 MB View Download

Could you triage this to someone or keep debugging bo?