Note:
Kindly refer the below link for referring Screen-Cast

https://drive.google.com/drive/folders/0B6HnShxaTyMddnI3V0ZQT1VXbGM?usp=sharing

Please triage. I work on iOS, and my CL couldn't have caused this. I have no idea how to triage non-iOS bugs, unfortunately. 

Correction:

Using the per-revision bisect providing the bisect results,
Good Build: 58.0.3018.0(Revision:451538)
Bad Build: 58.0.3019.0(Revision:451676)

You are probably looking for a change made after 451656 (known good), but no later than 451657 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.

https://chromium.googlesource.com/chromium/src/+log/60698ac0ece866407aafdab0a71d18068ff111bc..d0286404a0fdb943d9e69ea7af0ffc85e0435f87

Suspect: https://chromium.googlesource.com/chromium/src/+/d0286404a0fdb943d9e69ea7af0ffc85e0435f87

@fs: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thank You!

That CL doesn't modify any code (it modifies a test), so it would have no effect on the matter at hand.
Maybe the issue doesn't always happen, and thus bisection can be difficult/unreliable.

Access to the video file in drive is restricted; can you unrestrict or add the video as an attachment here?

Note:
Kindly refer the below link for referring Screen-Cast

https://drive.google.com/drive/folders/0B3ztNsc-sGg4VzBDZWwzbDM5cEU?usp=sharing

Looks like a painting problem in blink?

Over to compositing folks.

Re-ran the bisect. This time I came up with:

https://chromium.googlesource.com/chromium/src/+log/36d0286404018e441692f66d1289f33ff33a05d1..e59c7d48269c8900a94b9158680ca67a02c5e418

Upon running it again, I got a different bisect. It seems this regression came and went a few times.
https://chromium.googlesource.com/chromium/src/+/75c75092b256d5e3e0ae7ecafd1f8b3430246e1b
is the best clue I think. I think there are invalidations happening for some reason, and before this
patch (a revert of an optimization in this area by Xianzhu) we were in a mode where we would not
invalidate the whole window.

The reason it blinks is I think because the image decode cache gets blown, though that is just a guess.
However: the image decode cache should not be blown by background tabs, since they shouldn't be
committing frames.

+khushalsagar, +wangxianzhu for any insights.

This looks like a browser compositing issue to me. Even if blink is invalidating, the compositor wouldn't push a frame with missing content for what's already visible.

Agreed. Changing component.

It didn't look tile related so I thought it must be a paint/invalidation problem. I'll try get a trace to see what is what.

I can't reproduce on linux TOT, exactly.

What I see is that after chrome://restart, as background tabs are loading, parts of the image go from being crisp to being pixelated/low res (but not the whole image - I think from around where the text is to the bottom of the page, which roughly matches what's grey in the video in #2.

I can't see how the display compositor would make a tile become low res like that. Back to you khushalsagar?

This is desktop so it shouldn't be the renderer using low res tiles, that's android only. I'll try to repro.

Yeah I don't think it's compositor low res tiles, the text itself isn't changing. It looks like a partially-decoded image kinda.

If I disable the use of partially loaded images in blink, I can repro the bug exactly (thanks for the partially-decoded image hint!). Narrowed down precisely to this: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/loader/fetch/Resource.cpp?type=cs&sq=package:chromium&l=588

DestroyDecodedDataForFailedRevalidation in Resource::RevalidationFailed destroys the image and the new image used has partial data. Since this image has partial data, the next frame uses a partially decoded image. This case has a weird interaction with the resource cache because I think all tabs are rendered in the same process so there's multiple requests for the same resource simultaneously. The higher number of tabs you open, more easily you'll be able to observe the bug.

Changing the component to Blink>Loader. I hope that's the correct one for this?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

+mkwst@, could you triage this please? Last I debugged this, it came down to this: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/loader/fetch/resource.cc?type=cs&q=DestroyDecodedDataForFailedRevalidation+file:%5Esrc/third_party/blink/renderer/platform/loader/+package:%5Echromium$&g=0&l=1040

I think the fix need to be in the resource loading stack.