Closed Bug 1623548 Opened 5 years ago Closed 2 years ago

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

Categories

(Core :: Graphics, defect, P3)

Desktop
Linux
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr68 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- fix-optional
firefox78 --- fix-optional

People

(Reporter: hiro, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Attached video A record of the garbage (deleted) —

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

Priority: -- → P2

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

Flags: needinfo?(hikezoe.birchill)
Attached file about:support (deleted) —

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.

Flags: needinfo?(hikezoe.birchill)

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

Flags: needinfo?(hikezoe.birchill)

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.

Flags: needinfo?(hikezoe.birchill)

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.

Flags: needinfo?(gwatson)

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?

Flags: needinfo?(gwatson)

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

No longer blocks: wr-76

Does it reproduce for you on Windows?

Flags: needinfo?(hikezoe.birchill)

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

Flags: needinfo?(hikezoe.birchill)
Priority: P2 → P3

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.

Version: unspecified → Trunk

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

Flags: needinfo?(aosmond)

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?

Flags: needinfo?(aosmond) → needinfo?(sotaro.ikeda.g)

(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.

Flags: needinfo?(sotaro.ikeda.g)

:mattwoodrow, can you comment to this bug?

Flags: needinfo?(matt.woodrow)

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.

Flags: needinfo?(matt.woodrow)

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

OS: Unspecified → Linux
Hardware: Unspecified → Desktop
Summary: Flickers or remaining garbage of background tab → Flickers or remaining garbage of background tab (Basic compositor)

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

Summary: Flickers or remaining garbage of background tab (Basic compositor) → Flickers or remaining garbage of background tab (Basic + OpenGL compositor)
Has Regression Range: --- → yes

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.)

Severity: normal → S3

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

Flags: needinfo?(jan)
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(jan)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: