Flickers or remaining garbage of background tab (Basic + OpenGL compositor)
Categories
(Core :: Graphics, defect, P3)
Tracking
()
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)
Steps to reproduce
- Load http://codepen.io/dropside/full/MYGKyj/ in a tab
- Open a new tab
- load about:config in the new tab
- 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
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Hiro, can you add the contents of about:support as a text file please? Thanks!
Reporter | ||
Comment 2•5 years ago
|
||
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•5 years ago
|
||
The regression range seems from quite a while ago - does this seem like a newer issue to you, out of curiosity?
Reporter | ||
Comment 4•5 years ago
|
||
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•5 years ago
|
||
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.
Updated•5 years ago
|
Comment 6•5 years ago
|
||
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?
Reporter | ||
Comment 7•5 years ago
|
||
Yes, this is an issue on non-WebRender, I don't see the issue on WebRender.
Reporter | ||
Comment 9•5 years ago
|
||
No, I can't reproduce this on my Windows laptop (thinkpad t460p).
Updated•5 years ago
|
Comment 10•5 years ago
|
||
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.
Updated•5 years ago
|
Comment 11•5 years ago
|
||
Andrew, you mentioned seeing something similar with images in the past - any suggestions here? This is not WebRender, it appears.
Comment 12•5 years ago
|
||
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?
Updated•5 years ago
|
Comment 13•5 years ago
|
||
(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 15•5 years ago
|
||
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•5 years ago
|
||
Confirmed with Basic Compositor of Firefox ESR 68.7.0esr-1.
Comment 17•5 years ago
|
||
OpenGL is also affected (I see my desktop background), WebRender not.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 18•5 years ago
|
||
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•2 years ago
|
||
Basic Compositing was removed in bug 1727876. Should this be closed?
Updated•2 years ago
|
Description
•