can you attach an apk and exact steps to reproduce the problem?

1.  Login using the following credential
   user name: user.demo@gmail.com
   password : advantage

2. After login choose Gurgaon as city (please turn off your location otherwise it will auto-select the location)

3. Go to search (search icon on top right corner)
4. Search "Max" and click on "Max Healthcare"
5. Scroll down to location section and then wait for 3-4 second and scroll up slowly. 
6. Either Terms & Condition or How To Avail section will be blank. 
7. Please try this 3-4 times because sometimes bug doesn't show off.
 Note: Issue occurs in Android N device with the latest Chrome.

Thanks

Deleted: app-release.apk 8.9 MB

app-release.apk 8.9 MB Download

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

Yep, can reproduce the issue. worth investigating more.

but I have a question. Are you calling setLayerType(LAYER_TYPE_HARDWARE) on any webview's parent views? It doesn't really help with performance, and it's probably making the bug worse.

No, I am not calling setLayerType(LAYER_TYPE_HARDWARE) on any WebView's parent views. 

 Issue 740021  has been merged into this issue.

please consider this as either pri 2 or pri 1

This issue persists on Chrome dev build version 61 as well.

I'll take a more detailed look today

+sunnyps: see attached trace with cc.debug.scheduler, from a local trunk build.

Summary is something did not SetNeedsRedraw. Interesting bit of trace starts at ~2.35s. At 2.35s, compositor is invisible, begin frame source is paused, and tile budget set to 0, and presumably all tile resources are dropped.

Then webview becomes visible and things starts to get back to visible state.

First OnDraw happens at 2,378.756ms, this one comes in while compositor is still invisible/bfs paused; it does a ScheduledActionPrepareTiles, but no raster is scheduled because no budget. All is normal afaict.

Second OnDraw happens at 2,406.794ms, as a consequence of becoming visible. At this point, compositor is visible, bfs unpaused, and everything is back to its "normal" state. PrepareToDraw returns DRAW_ABORTED_MISSING_HIGH_RES_CONTENT and actual draw is skipped, which I guess this makes sense due to no tiles rastered yet. However, this left needs_redraw_ false, and the subsequent ScheduledActionPrepareTiles scheduled no tiles.

Then for all subsequent frames, no frame is produced because needs_redraw_ is false.


So what's the expectation here? Does renderer still assume display compositor is holding onto its last frame? What's supposed to SetNeedsRedraw after DRAW_ABORTED_MISSING_HIGH_RES_CONTENT? I'm guessing tile raster being finished, but then it did not end up scheduling any raster tasks. Also SchedulerStateMachine::DidDrawInternal sets needs_redraw_ for DRAW_ABORTED_CHECKERBOARD_ANIMATIONS, but not for DRAW_ABORTED_MISSING_HIGH_RES_CONTENT case? Looks like the commit was just aborted for no update.

Deleted: trace_740544.zip 222 KB

trace_740544.zip 222 KB Download

SchedulerStateMachine::DidDrawInternal sets needs_begin_main_frame_ for DRAW_ABORTED_MISSING_HIGH_RES_CONTENT. That doesn't work in this case because the main frame is aborted and then the compositor doesn't do anything.

Also FWIW the assumption was that the synchronous compositor would call SetNeedsRedraw before OnDraw. All of the scheduler unittests do this. However, this has changed and LayerTreeHostImpl::SetExternalTilePriorityConstraints only calls SetNeedsRedraw when the tile priority changes.

The correct fix is to set needs_redraw_ in for DRAW_ABORTED_MISSING_HIGH_RES_CONTENT.

Ok, finally back to this again.

Simply adding needs_redraw_ = true didn't fix this completely. See trace. It is spinning draw now, but there is still missing tile in every draw.

There are two PrepareTiles, but they both end up not doing any work afaict. So something else weird is happening..

Memory state looks fine, but 0 tiles.
{tile_count: 0,
 did_oom_on_last_assign: false,
 global_state: {memory_limit_policy: "ALLOW_PREPAINT_ONLY",
                soft_memory_limit_in_bytes: 15728640,
                hard_memory_limit_in_bytes: 31457280,
                num_resources_limit: 10000000,
                tree_priority: "SAME_PRIORITY_FOR_BOTH_TREES"}}

hmm, is frameviewer trace not a thing anymore?

> hmm, is frameviewer trace not a thing anymore?

oh nvm, LayerTreeHostImpl::DrawLayers never happens :/

ahh, real culprit is missing a set_needs_update_draw_properties. nothing to do with scheduler :)

* LayerTreeHostImpl::SetMemoryPolicy calls ReleaseTileResources to drop all tiles
* PictureLayerImpl::ReleaseTileResources calls ResetRasterScale. Meaning it needs UpdateTiles called again to be drawn
* Nothing actually calls UpdateTiles, since LayerTreeImpl::UpdateDrawProperties just early returns, so things just get stuck.

Adding set_needs_update_draw_properties after ReleaseTileResources seem to solve this, although not sure if that's the place to do this. +enne for thoughts?


I think for the situation in scheduler described in #12/13, the expectation is tile manager finishing raster will trigger another frame.

Yeah, I think set_needs_update_draw_properties seems reasonable there so that the UpdateTiles in LayerTreeImpl occurs.  I'm a bit surprised that this worked in the general case, but there's probably something else setting this flag.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5407ae96d0ce9b803b40aa74dd86719c5f722a80

commit 5407ae96d0ce9b803b40aa74dd86719c5f722a80
Author: Bo Liu <boliu@chromium.org>
Date: Mon Aug 21 19:47:52 2017

cc: set_needs_update after dropping tile resources

PictureLayerImpl::ReleaseTileResources calls ResetRasterScale, meaning
it needs UpdateTiles called again to be drawn. If nothing else calls
set_needs_update_draw_properties, then everythiing just gets stuck.

So add a set_needs_update_draw_properties after
LTHI::ReleaseTileResources. And add a test that would have failed
without the fix.

Bug:  740544 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ifd2027e17dc0285054ae3b038c6808d94eafba50
Reviewed-on: https://chromium-review.googlesource.com/621253
Reviewed-by: enne <enne@chromium.org>
Commit-Queue: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#496030}
[modify] https://crrev.com/5407ae96d0ce9b803b40aa74dd86719c5f722a80/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/5407ae96d0ce9b803b40aa74dd86719c5f722a80/cc/trees/layer_tree_host_impl_unittest.cc

I think this is a pretty safe one-line change, and there should be one more beta in m61 to try this. So merging to m61

This bug requires manual review: M61 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid@(ChromeOS), govind@(Desktop)

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

Approved for M61 branch 3163.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3a3c11cd37194597fbeac13417bfe91a1f21aca1

commit 3a3c11cd37194597fbeac13417bfe91a1f21aca1
Author: Bo Liu <boliu@chromium.org>
Date: Tue Aug 22 20:44:39 2017

[Merge m61] cc: set_needs_update after dropping tile resources

PictureLayerImpl::ReleaseTileResources calls ResetRasterScale, meaning
it needs UpdateTiles called again to be drawn. If nothing else calls
set_needs_update_draw_properties, then everythiing just gets stuck.

So add a set_needs_update_draw_properties after
LTHI::ReleaseTileResources. And add a test that would have failed
without the fix.

(cherry picked from commit 5407ae96d0ce9b803b40aa74dd86719c5f722a80)

Bug:  740544 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ifd2027e17dc0285054ae3b038c6808d94eafba50
Reviewed-on: https://chromium-review.googlesource.com/621253
Reviewed-by: enne <enne@chromium.org>
Commit-Queue: Bo <boliu@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#496030}
Reviewed-on: https://chromium-review.googlesource.com/627384
Reviewed-by: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#780}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/3a3c11cd37194597fbeac13417bfe91a1f21aca1/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/3a3c11cd37194597fbeac13417bfe91a1f21aca1/cc/trees/layer_tree_host_impl_unittest.cc

I have a question, is this is live? Because I am still facing the same problem.

Fix landed in 62.0.3193.0 on trunk, then merged to 61.0.3163.60

Ok thanks