piman@, is this a known issue?

Not anything that I know of. Sounds like a device-specific issue if it doesn't happen on linux.

Re #2, I can repro this on both nocturne and caroline. Does this sound like a blur bug, or I used it in a wrong way?

I'm really not sure. Perhaps Dana has an idea.

Update for this issue: It does not exist on device kevin, it might be intel device specific bug. Is it possible that it's related to  bug 824564 ?

It might be not related to  bug 824564 , do you have any idea about this issue?

It is still a problem on ToT

As yo usay, similar to 824564, I guess if this is on intel only:

"Note that this is probably a skia GPU rast bug. We only enable skia GPU rast on intel devices for now."

Have you tried disabling gpu raster to compare? https://cs.chromium.org/chromium/src/ui/base/ui_base_features.cc?rcl=0b9fcfe9befdf310f87c1ba2116b0a16a36f0645&l=69

Re #11
I just enabled/disabled gpu raster in chrome://flags/#enable-gpu-rasterization, the issue exists in both cases.

That is for web content not ui, right? I linked to the UI specific feature.

I tried disable/enable here [1], but the issue exists in both cases too.

On update: The issue will disappear when I make the search box invisible, it seems that search box background color will affect the blur color.

[1] https://cs.chromium.org/chromium/src/ui/base/ui_base_features.cc?rcl=0b9fcfe9befdf310f87c1ba2116b0a16a36f0645&l=78

Thanks. The background blurs are done in the compositor on the gpu similar to gpu raster, so that could still be an intel-specific problem (in skia?) like 824564. I can't tell from that bug how it was fixed to suggest something further.

I'm not really sure how to help here. How would I reproduce and debug this?


We have an image test suite that can be run on ChromeOS devices. It might help to run it and see if our existing tests reproduce something like the bug you're seeing.

This could be reproduced with 3 lines of code added [1]. You will see the background blur flickers when you scroll the page up and down.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/1210947

Great. To run that do I need to build ChromeOS and install on a device?

Yes, it only happens on intel device.

I'm not sure what I'm doing wrong, but I'm having trouble reproducing this.

I built Chrome for Chrome OS and installed it using the instructions here:https://chromium.googlesource.com/chromiumos/docs/+/master/simple_chrome_workflow.md

I used this ChromeOS image:
https://storage.cloud.google.com/chromeos-releases/canary-channel/eve/11021.0.0/ChromeOS-test-R70-11021.0.0-eve.tar.xz

I've tried both these CLs when building Chrome:
https://chromium-review.googlesource.com/c/chromium/src/+/1210947
https://chromium-review.googlesource.com/c/chromium/src/+/1171546

I verified that GPU raster and compositing are enabled. I installed a bunch of Chrome apps in order to make the app list in the launcher scrollable. However, I don't see the issue.

Video: https://drive.google.com/open?id=1RUjB4GXg9OourhZhfUW3FljDknAWMs79

#20, did you apply the patch in #17?

Yes, first I tried that patch, then I tried the patch in the original report.

Oh, eve enables background blur by default. So the blur on suggestion chip does not flicker in that case. You might need to disable chrome://flags/#enable-background-blur

Thanks, that worked!

Yesterday I tested a bunch of different theories as to what could be happening (mostly around state leaks between cc and Skia and potential driver bugs). Nothing I tried panned out.

Today I rebased my branch on origin/master and I can no longer reproduce this. Can you confirm that?

The issue is still seen on ToT: ChromeOS 71.0.3550, Chrome 11057.0.0. I tested on device caroline.

I got it reproducing again. This appears to either be a views or cc issue. The search bar widget is sometimes included in the background for the suggestion chips and sometimes is not. The flicker is caused by the contribution of the search bar in the blur happening in some frames and not others.

I hacked things up so that the search bar background is bright green. This makes the flicker green and more noticeable.

Then in viz::GLRenderer::ApplyBackgroundFilters I made it so that it ignores the filter and just draws the background translated by -90, -90 which is roughly the offset to top left pixels that would contribute to a blur with sigma 30. This makes it obvious that the search bar is sometimes in the background texture and sometimes not. You can see that in this video:
https://drive.google.com/open?id=1_WBsQEFCBcfIJJLMbwtvvFx4sBLitxKD

Dana, kicking this back to you in hopes that you have some intuition about where this should go next. It seems like it might have something to do with incorrect layer squashing in cc or perhaps views should be explicitly putting something in a layer but I'm really out of my league there.

Thanks Brian. Really lost why this would be an intel-only thing in this case.

FWIW cc doesn't squash layers (blink does), so it works with whatever scene ui::compositor/views hand to it.

Brian could you share the patch you used to demonstrate this with the green?

It looks like while scrolling up, the search bar gets occluded (or clipped?) from the blur filter somehow, without being occluded on the screen. I haven't any idea why that would happen, but if the buttons are making a blur from their background with that large of a radius, and are being drawn after the search box.. then they will include it.

Perhaps the buttons could be placed before the search box in the layer tree (postorder traversal), so that they are not blending the search box into their blur filter?

I'm not sure if this is supported by filters, but if a clip could be placed on the filter, that could maybe resolve it. Or reduce the blur radius to not include the area of the search box.

It's hard to tell from the original video why background blur is being used to implement this effect when the background behind the buttons is simply black. Perhaps a blur that isn't a background filter could be used as well (also that'd be much more efficient).

I had the same question about why a blur is used. I couldn't tell that it was a blur.

I attached a patch that colors the search bar green and then draws the translated background rather than running it through a filter.

Deleted: hacks.diff 1.7 KB

hacks.diff 1.7 KB Download

Thanks a lot for investigating this issue, the search box is in fact in a different widget with suggestion chip, so it might be hard to reorder the layer tree.
I changed the blur from 30 to 5, the flicker does not occur any more. I need to talk about this with UX to see what blur radius we should use. For now, I think we could mark this as won't fix.