i suspect the blur is too heavy for those devices, i can see it flicker occasionally on pixelbook as well. Can you verify if it happens if you enable the
--ash-disable-login-dim-and-blur flags?

C#2-->

Checked the issue by enabling the flag --ash-disable-login-dim-and-blur on Reks device with chrome version 68.0.3400.0/10600.0.0 dev 
and unable to reproduce the issue

Thanks!

kebalaji@ - Thanks for checking.

Ben, it seems like the blur animation may be a bit much. Blur itself i think is pretty expensive, now we trying change the blur many times in a second. Any thoughts?

It's hard to make a judgement about the severity of the flickering without seeing it in person. I can't repro on my pixelbook. I also wonder how often it repros with slower overview toggling or a single button press.

Is this a regression? My thought is that it's a nicely-implemented feature that would be a shame to lose, even if we limited the disabling to lower-powered devices. If it's a regression and not that severe, I would prefer to keep the bug open at a lower priority.

Otherwise, the alternatives would be to not animate and do a jump cut (not desirable) or animate a crossfade between a pre-rendered blurred wallpaper bitmap and the non-blurred wallpaper (will produce a slightly different, less desirable effect, but likely a much lighter-weight animation).

I think if you spam the overivew button on your pixelbook it should show up once every five times ish. I would think if the button is used normally the repro rate should go down a lot.

Its not really a regression, it is more like a side effect of a new feature. The new feature being go from jump cut blur to animated blur. I agree this probably shouldn't be stable blocking.

Comment #6 says it should not be RSB, can we please remove that label?

Removing RBS per #6.