1595038 - [macOS] 1px horizontal line flickering glitch when scrolling

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect, P2)

Description

[PushBug]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

1. Visit https://www.newstatesman.com/why-trust-science-naomi-oreskes-review
2. Scroll up and down the page beneath the image a few times
3. Look for 1px horizontal lines will flickering on the screen

Actual results:

Horizontal lines flicker on the page. This occurs on several different websites. Reproduced on both 13" and 15" MacBook Pro models as well as Mojave and Catalina.

Expected results:

No rendering artifacts.

Comment 1

[PushBug]

Attachment: Screen Recording 2019-11-08 at 12.37.50.mov

Comment 2

[Cristian Craciun]

Build ID 20191030021342
User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:70.0) Gecko/20100101 Firefox/70.0

I didn't managed to reproduce this issue on Release(70), Beta(71) or Nightly(72) version, either on Mojave or Catalina using a MacBook Pro 15". I've tried also to reproduce it on High Sierra and on different hardware (iMac).

Could you please provide more information related to this issue? Could you try to reproduce this issue using a new profile? You can find more information here: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles

Comment 3

[PushBug]

(In reply to Cristian Craciun from comment #2)

...

Build ID 20191111170815
User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:71.0) Gecko/20100101 Firefox/71.0

I created a new test profile and found that the issue still occurs (also on the default profile).

Additionally, I found that the line appears and disappears when the width of the window is resized but seems to always happen in fullscreen (see the newly attached video).

Note that this glitch doesn't always appear when visiting the page but I can consistently reproduce it.

Comment 4

[PushBug]

Attachment: Screen Recording 2019-11-13 at 15.56.55.mov

Comment 5

[PushBug]

The position window.scrollY where the line appears continuously doesn't seem to be fixed.

Comment 6

[Simona Badau, Desktop QA]

I can confirm this issue, reproduced it on an MacBook Pro (retina, 15") on version 10.14 and version 10.15 using the latest Nightly 74.0a1, Firefox 72 and Firefox 73 beta 1. I could not reproduce this issue on Firefox 68.4.0 esr.

Please note that the issue is not reproducible when I disable the hardware acceleration from Preferences.

Comment 7

[Simona Badau, Desktop QA]

Last good revision: 9798d276348f91a467897783525134fe2b10723a
First bad revision: 8e2dfb26c66ce8f6a48bb1ba2f9d2a4ca6d884fe
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9798d276348f91a467897783525134fe2b10723a&tochange=8e2dfb26c66ce8f6a48bb1ba2f9d2a4ca6d884fe

Comment 8

[Simona Badau, Desktop QA]

Markus, could you please take a look over?

Comment 9

[Jens Stutte [:jstutte]]

Hi Simona, can you still reproduce this with the latest Nightly? Here we cannot see it.

Comment 10

[Simona Badau, Desktop QA]

(In reply to Jens Stutte [:jstutte] from comment #9)

Hi Simona, can you still reproduce this with the latest Nightly? Here we cannot see it.

Yes, even if the issue is not as noticeable as it used to, I can still reproduce it on the latest Nightly 75.0a1 and MacBook Pro (Retina, 15-inch, Mid 2015). Resizing the browser's window makes the issue easier to reproduce - there is a horizontal line that flickers under the photo.

Please see the video:
https://imgur.com/a/aBuIi9e

Comment 11

[Markus Stange [:mstange]]

I can reproduce it in fullscreen mode. Going to take a look.

Comment 12

[Markus Stange [:mstange]]

Attachment: testcase

At certain window widths, this testcase displays a blue horizontal line somewhere in the window.

It looks like the ImageLayer clip is offset / off-by-one somewhere.

Comment 13

[Markus Stange [:mstange]]

Attachment: WebGL testcase for Intel driver bug

This is caused by an OpenGL driver bug. The scissor rect does not intersect the viewport, but the closest edge pixels in the viewport still end up getting filled.

This does not reproduce when the discrete GPU is used.

We can work around it in the compositor - there's no need to draw when the clip rect doesn't intersect the viewport. But maybe we also need a workaround for WebGL.
Safari and Chrome show the same WebGL bug.

Comment 14

[Markus Stange [:mstange]]

Attachment: Rendering of WebGL testcase on the affected machine

Comment 15

[Markus Stange [:mstange]]

I have filed this bug with Apple as FB7642471.

Comment 16

[Markus Stange [:mstange]]

Attachment: Bug 1595038 - Add a planeNormal variable so that it's clear that the same plane is used for the entire inner loop. r=kip

Comment 17

[Markus Stange [:mstange]]

Attachment: Bug 1595038 - Stop normalizing the plane normals, in order reduce error from floating point inaccuracies. r=kip

For example, if the clipping rectangle has aClip.X() == 1024, then the normal for the clipping plane induced by the left edge of the clip will now be (1, 0, 0, -1024) rather than (0.0009765620343390458, 0, 0, -0.9999995231631829).

This change is mathematically valid:

• The dot products computed from these vectors become multiplied by planeNormal.Length() (compared to before this patch).
• The sign of the dot products is not affected, so the "intersection with plane" check is not affected:
  if ((nextDot >= 0.0) != (prevDot >= 0.0)) {
• The value of the dot products is only used to compute t, as follows:
  F t = -prevDot / (nextDot - prevDot);
  Here, the length now appears both in the numerator and in the denominator, canceling itself out.

As a result from this change, the existing tests no longer require integer nudging in order to pass.

Depends on D68702

Comment 18

[Markus Stange [:mstange]]

Attachment: Bug 1595038 - Make sure that TransformAndClipBounds returns an empty clipped rect when the clip itself is already empty. r=kip

The test added in this changeset is already fixed by the no-normalization change, but there are probably cases that require the explicit check that this patch adds.
When we were still normalizing the plane normals, the TransformAndClipBounds call in the added test was returning (1023.999878, 1023.999878, 0.000061, 0.000122).

Depends on D68703

Comment 19

[Markus Stange [:mstange]]

These patches fix the bug because we will now return early from DrawGeometry at the destRect.IsEmpty() check in the problematic case. If the clip does not intersect the render target, we pass an empty aClip to TransformAndClipBounds, so we will now get a destRect that's guaranteed to be empty after these patches.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e51404852968
Add a planeNormal variable so that it's clear that the same plane is used for the entire inner loop. r=kip
https://hg.mozilla.org/integration/autoland/rev/37a849a3f226
Stop normalizing the plane normals, in order reduce error from floating point inaccuracies. r=kip
https://hg.mozilla.org/integration/autoland/rev/ac2c160ca492
Make sure that TransformAndClipBounds returns an empty clipped rect when the clip itself is already empty. r=kip

Comment 21

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/e51404852968
https://hg.mozilla.org/mozilla-central/rev/37a849a3f226
https://hg.mozilla.org/mozilla-central/rev/ac2c160ca492