At least two places where we set needs redraw that causes this:
1. In ui::Compositor::ScheduleFullRedraw (e.g. after the display configuration changes in ash)
2. LTHI::WillBeginImplFrame - we check the likely_to_require_a_draw flag that's set by PrepareTiles when we're still rasterizing required for draw tiles. I think in this case we only really want another begin frame and not redraw.

> 2. LTHI::WillBeginImplFrame - we check the likely_to_require_a_draw flag that's set by PrepareTiles when we're still rasterizing required for draw tiles. I think in this case we only really want another begin frame and not redraw.

We're actually scheduling a draw when the deadline comes, since we're expecting some raster to complete inside the frame.

This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

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

So I'm unclear why we wouldn't allow this ordering in general. If the main frame takes longer than the impl deadline and we're doing any kind of impl-side updating, then the other option is to abort the main frame which seems wrong?

I agree. I don't quite remember the motivating example I had when filing this bug, but I agree that everything should work properly.

Cautiously closing this.