1623548 - Flickers or remaining garbage of background tab (Basic + OpenGL compositor)

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P3)

Description

[Hiroyuki Ikezoe (:hiro)]

Attachment: A record of the garbage

Steps to reproduce

1. Load http://codepen.io/dropside/full/MYGKyj/ in a tab
2. Open a new tab
3. load about:config in the new tab
4. Switch to the original tab

You will see garbage at the top of the contents.

The regression range is probably
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b266a8d8fd595b84a7d6218d7b8c6b7af0b5027c&tochange=035c25bef7b5e4175006e63eff10c61c2eef73f1

Comment 1

[Jessie [:jbonisteel] pls NI]

Hiro, can you add the contents of about:support as a text file please? Thanks!

Comment 2

[Hiroyuki Ikezoe (:hiro)]

Attachment: about:support

This file is written in Japanese, sorry about that, I couldn't find a way to output it in English on my environment.

Anyways, this is a pretty new profile.

Comment 3

[Jessie [:jbonisteel] pls NI]

The regression range seems from quite a while ago - does this seem like a newer issue to you, out of curiosity?

Comment 4

[Hiroyuki Ikezoe (:hiro)]

Yes, I noticed this issue a week ago. Initially I thought it's caused by my local patches for bug 1324591, I've been using the codepen for a test case for the bug (the codepen case is originally reported for bug 1213513). Before I started working on bug 1324591 I had never noticed the issue.

Comment 5

[Andrew Osmond [:aosmond] (he/him)]

When I've seen this myself with images (before I fixed it), it was often because an image was marked as opaque, but actually contained alpha, and it messed up the compositing.

Comment 6

[Glenn Watson [:gw]]

I haven't been able to reproduce this - I tried with both WR enabled and disabled.

However, it looks like in the about:support log the compositor is Basic which would suggest that it's unrelated to WR?

Could you confirm whether it occurs with both Basic and/or WR compositor enabled?

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Yes, this is an issue on non-WebRender, I don't see the issue on WebRender.

Comment 8

[Jessie [:jbonisteel] pls NI]

Does it reproduce for you on Windows?

Comment 9

[Hiroyuki Ikezoe (:hiro)]

No, I can't reproduce this on my Windows laptop (thinkpad t460p).

Comment 10

[Negritas Sergiu, Desktop QA]

Hello i have managed to reproduce the issue on Linux 18.04 LTS x64 using Fx 74.0 , 75.0b8 and Fx 76.0a1. I will update the flags accordingly.

Comment 11

[Jessie [:jbonisteel] pls NI]

Andrew, you mentioned seeing something similar with images in the past - any suggestions here? This is not WebRender, it appears.

Comment 12

[Andrew Osmond [:aosmond] (he/him)]

Sorry, I thought it was WebRender rather than Basic compositor. Maybe something in the layer tree is going wrong and it is putting the wrong piece in (on the cursor flash cadence)? I'm not really much of an expert on this. Any ideas Sotaro?

Comment 13

[Sotaro Ikeda [:sotaro]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #0)

The regression range is probably
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b266a8d8fd595b84a7d6218d7b8c6b7af0b5027c&tochange=035c25bef7b5e4175006e63eff10c61c2eef73f1

I could reproduce the problem with latest m-c on linux. I wonder if it might be a regression by Bug 1361970. When ShouldProcessLayer() always returned true, I did not see the flickering, though rendering was still not correct.

Comment 14

[Sotaro Ikeda [:sotaro]]

:mattwoodrow, can you comment to this bug?

Comment 15

[Matt Woodrow (:mattwoodrow)]

I agree that bug 1361970 is the most likely cause of the regression.

The flickering is likely due to double buffering, and we're computing the wrong dirty region (likely thinking that the header bar is occluded) and never clearing that area of pixels in one of the buffers.

It looks like the header bar is behind the page content, so I'd guess that we're failing to take the page content's clip into account (possibly due to it being on an intermediate layer?) when computing the visible area of the header bar and thus think that the header bar is hidden behind the page content. When computing the visible area of the page content though, we do clip, so don't mark the pixels in the area of the header bar as being visible/dirty.

The expectation is that when we skip intermediate Layers, we still apply their clips to children via the aClipFromAncestors.

I'd have to actually debug to get any further though sorry, which I don't have much time for right now.

In the past I've had success with enabling layer dumping (of the compositor layer tree - layers.dump=true), and adding logging to the PostProcessLayers code.

Comment 16

[Darkspirit]

Confirmed with Basic Compositor of Firefox ESR 68.7.0esr-1.

Comment 17

[Darkspirit]

OpenGL is also affected (I see my desktop background), WebRender not.

Comment 18

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Comment 19

[Gregory Pappas [:gregp]]

Basic Compositing was removed in bug 1727876. Should this be closed?