1719280 - Interlacing artifacts on Fenix Nightly

Status: RESOLVED DUPLICATE of bug 1696905

(Core :: Graphics, defect, P3)

Description

[Petru-Mugurel Lingurar [:petru]]

Attachment: interlacing artifacts

From Fenix - https://github.com/mozilla-mobile/fenix/issues/10598#issuecomment-874551529

The issue is particularly bad when you scroll whilst using a video.. With video the whole screen flickers, when it happens without video playing there's just horizontal lines. The issue is also present when I use my on screen keyboard.

With keyboard not used, fixed address bar stable is fine.
With hidden address bar it happens when scrolling on stable.
With keyboard up it happens with scrolling and when typing on stable.
It seems to be triggered by any on screen movement, even happens with the cursor blinking waiting for text input or a moving advertisement on stable.

In nightly none of this happens at all.

Here's both about:support from stable where it's broken and nightly where it works fine.

Also attached is a screenshot showing the flickering lines on this very page.

Comment 1

[Petru-Mugurel Lingurar [:petru]]

Don't know if this is something that got fixed in the meantime but seems like an important issue to get more info about.

Comment 2

[Petru-Mugurel Lingurar [:petru]]

Attachment: image.png

Comment 3

[dodgexander]

Thank you @Mugurell sorry for hijacking the other issue.
This bug is happening only on stable, nightly doesn't have the problem. In my testing the horizontal lines can appear with white, not just black web pages.
Flicker in video is also regardless of page theme.
The flicker when typing however only happen with dark backgrounds.
Here's a video of all 3:
https://streamable.com/q6nmsx

Sorry about my parakeet and the tts in the video. I thought it was recording my phone sounds.

All three seem to be related and have something in common. If something is moving on the screen, be it the typing cursor, a video or an advertisement the flicker happens. If the auto hide address bar is disabled all flicker stops.

Comment 4

[Sotaro Ikeda [:sotaro]]

dodgexander, can you upload about:support of the device to this bug? Thank you.

Comment 5

[dodgexander]

Attachment: about:support stable.txt

Here's the about:support from stable which exhibits this bug.

Comment 6

[dodgexander]

Attachment: about:support from nightly.txt

Here's the about:support from nightly which does not exhibit this bug.

Comment 7

[Sotaro Ikeda [:sotaro]]

(In reply to dodgexander from comment #6)

Created attachment 9230031 [details]
about:support from nightly.txt

GPU was Adreno 530.

Comment 8

[Sotaro Ikeda [:sotaro]]

:jnicol, do you have an idea about a fix that addressed this problem on nightly.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

Comment 10

[Jamie Nicol [:jnicol]]

I can't think of anything off of the top of my head. Looks like a driver bug of some sort. I have a device with an Adreno 530 running Android 8. However, it has an earlier Adreno driver version (251.0) than the reporter's (313.0). I cannot reproduce the issue in Firefox 89.

dodgexander, could you please try running mozregression to find out what fixed this issue for you.

You can either install a GUI application from that link, or if you're on Macos or Linux I find it easiest to install via the command line:

pip install --user mozregression

Then you tell it that version 89 was bad, 91 is good, and that you want to find the fix. And to use the "geckoview_example" or "gve" app.

mozregression --find-fix --app gve --good 91 --bad 89

If using the GUI, you click the scissor icon to "start bisection", then you should be able to enter those settings in the GUI. This will download and run a series of versions of firefox. For each one you select "good" or "bad" and eventually it should tell you what commit fixed the bug.

Please let me know if you need any help with that. Thanks!

Comment 11

[dodgexander]

(In reply to Jamie Nicol [:jnicol] from comment #10)

I can't think of anything off of the top of my head. Looks like a driver bug of some sort. I have a device with an Adreno 530 running Android 8. However, it has an earlier Adreno driver version (251.0) than the reporter's (313.0). I cannot reproduce the issue in Firefox 89.

dodgexander, could you please try running mozregression to find out what fixed this issue for you.

You can either install a GUI application from that link, or if you're on Macos or Linux I find it easiest to install via the command line:

pip install --user mozregression

Then you tell it that version 89 was bad, 91 is good, and that you want to find the fix. And to use the "geckoview_example" or "gve" app.

mozregression --find-fix --app gve --good 91 --bad 89

If using the GUI, you click the scissor icon to "start bisection", then you should be able to enter those settings in the GUI. This will download and run a series of versions of firefox. For each one you select "good" or "bad" and eventually it should tell you what commit fixed the bug.

Please let me know if you need any help with that. Thanks!

Using the tool I get:
0:01.86 ERROR: The url 'https://hg.mozilla.org/mozilla-central/json-pushes?startdate=2021-04-19&tochange=91' contains no pushlog. Maybe use another range ?

So I tested beta (which seems to be version 90) and did the mozregression using that instead. This is the final output:

10:47.65 INFO: Narrowed integration fix window from [3aa883d4, de6dfc67] (3 builds) to [a224bb49, de6dfc67] (2 builds) (~1 steps left) 10:47.65 INFO: No more integration revisions, bisection finished. 10:47.65 INFO: First good revision: de6dfc676a6877428343a1c0fdbb099fc6b3ebfd 10:47.65 INFO: Last bad revision: a224bb494905453378576ed4e1bb8f615828f566 10:47.65 INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a224bb494905453378576ed4e1bb8f615828f566&tochange=de6dfc676a6877428343a1c0fdbb099fc6b3ebfd

Comment 12

[Jamie Nicol [:jnicol]]

Great, thanks.

I guess this was probably fixed by bug 1696905 then. Perhaps a driver issue to do with using the depth buffer when compositing picture cache tiles. We don't have plans to revert this so I think we're safe to mark this as fixed.