Can paint team confirm and triage?

FYI - might be same as bug 806032.

This does not seem to be painting, but rather something related to the GPU presenting frames.

Tested the issue in Android and able to reproduce the issue.

Steps Followed:
1. Launched the Chrome Browser.
2. Navigate to https://www.bloomberg.com/technology
3. Observed the flickering

Chrome versions tested:
66.0.3335.4(Canary)

OS:
Android 6.0.1

Android Devices:
Samsung S7

This seems to be a Non-Regression issue as same behaviour is seen since M58

Please navigate to below link for log's and video--
go/chrome-androidlogs/807056

Note: 
This issue is not observed in Desktop

Thanks!!

sandeepkumars@, just to confirm, you were able to reproduce this issue on M58 as well?

-> ericrk for triage

ping, sandeepkumars@, can you let me know about the question in #6 and assign back to me?

In response to comment #6

Observing inconsistent behaviour in the older and new builds as well. Please make sure to enable chrome-home-enable (Bottom tool bar) to reproduce the issue. 

Note: Issue isn't reproducible on scrolled near the top of the page with the top bar animating in/out.

Thanks!!

I can repro this on M64, but not M63 (although it may just be harder to repro there... not sure)...

Repro works on both actual devices (S7, Pixel 2 XL) and in desktop chrome using devtools device toolbar set to N6 mode.

Looking at the specific error, I think this is a partial raster issue - we're updating part of a tile, but leaving previous contents in the rest. Will continue looking.

Bisected this and it looks like it's caused by:

Prevent over-triggering of font invalidation (https://chromium-review.googlesource.com/730032)

My guess is that we're now under-invalidating something, causing us to fail painting over all required previous content when performing partial raster. It seems like some change to page style after initial load cause the animating image to jump down by ~200px, however we don't properly detect this change and fail to clear the appropriate content from the tile where it was previously located.

This repros on all Android devices I've tried, as well as on my Macbook Pro when set simulate a Nexus6 screen in devtools.

ksakamoto@, can you take a look?

I don't think failing to kick font invalidation can cause this kind of flickering.

Font invalidation causes full style recalculation, so it's possible that the symptoms has been masked by (unnecessary) font invalidation.

I'm downgrading this to a P2 because it does not affect the fundamental usage of the page (sure it's annoying, but ..) and in all likelihood we won't get it fixed quickly.

> I'm downgrading this to a P2 because it does not affect 
> the fundamental usage of the page (sure it's annoying, but ..) 
> and in all likelihood we won't get it fixed quickly.

do you really think that next stable could go without fix for it?

erikck@ I have 2 questions:

1. Did you need to enable top or bottom navigation bar to reproduce the issue on desktop with mobile emulation?

2. When it is blinking, do you think we are quickly swapping between a frame with correct raster and a frame with incorrect raster? If yes, what's your speculation of the reason that we have one correct frame and one bad frame?

ericrk@, could you answer the questions in #c15? (Sorry for the typo in the comment.)

For question 2, I'm not sure how an under-invalidation could cause that result. Your input would be helpful for me to debug the issue.

The blinking happens in the following situation:
- The URL bar is hiding in half way;
- The contents near the bottom of the screen is actively changing.

I believe this is not a paint invalidation issue but a cc rasterization issue, because I can reproduce the blinking in an area that we are actively invalidating. See the attached screen cast.

It seems that we are swapping between a correctly rasterized tile and a incorrectly rasterized tile. The tiles was out of the viewport when the URL bar was visible.  The incorrectly rasterized tile seems not updated when it becomes visible when the URL bar is hiding.

ericrk@ feel free to assign back to me if the above theory is incorrect. Please also let me know how you tested on Mac with mobile emulation. I just couldn't get the URL bar so could'n reproduce the bug with mobile emulation.

Deleted: 20180216_115149.mp4 4.1 MB

	20180216_115149.mp4 4.1 MB View Download

Sorry for the delay here - I missed these updates - please feel free to ping me on hangouts or assign back to me if you're ever waiting on a response.

Unfortunately, the issue you're reproducing in the attached video isn't the same one we're seeing here - you seem to be reproducing issue 806032, which is unrelated, but can happen on this page as well :/ - That has been fixed, so if you try to repro on the latest Canary, confusion should be avoided.

The issue being reported here is unrelated to the top/bottom bar. I believe that the comment in #9 is also seeing issue 806032, which is unrelated.

I'll do a bit more investigation to make sure I'm not mis-assigning this.

> I just couldn't get the URL bar

Home interface should be enabled with chrome://flags?

Re #19, this bug does not depend on Home (or the URL bar at all) - There was some confusion with  issue 806032 which does, and has similar effects. That has been fixed.

Re #20 - good points, thx and indeed, I don't see problem in 66.0.3350.0 anymore

I was looking into this again and have confirmed that it was recently fixed by:
https://chromium-review.googlesource.com/c/chromium/src/+/923572 - Enable slimming paint V175

Given that this bug already shipped in M64, I don't know that it's worth rushing to get something into M65 Beta. I think we can let SPV175 roll out through M66.

wangxianzhu@, please feel free to re-open if you think this warrants more investigation.