1385961 - Glitch on scroll

Status: VERIFIED FIXED

(Core :: Graphics: Layers, defect)

Description

[Emmanuel Counasse]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170730100307

Steps to reproduce:

- got to https://fritz-c.github.io/react-sortable-tree/
- fully deployed every nodes
- scroll to the top
- take the first node and tries to drop it at the end



https://github.com/webcompat/web-bugs/issues/8249#issuecomment-318938217


Actual results:

The viewport automatically scroll and produced graphical gliches 

See:
https://github.com/webcompat/web-bugs/issues/8249#issuecomment-318938217


Expected results:

The viewport automatically scroll without rendering gliches

Comment 1

[Emmanuel Counasse]

This is reproducible on some Windows 10 machines with GPU.

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Any chance of a video/image of when the problem happens, as I don't see it?  Since it seems device specific, can you attach the about:support of the configuration that does have this problem?

Comment 3

[Emmanuel Counasse]

Attachment: ScreenCast of the problem as a gif

Comment 4

[Emmanuel Counasse]

Attachment: about:support content

Comment 5

[Emmanuel Counasse]

(In reply to Milan Sreckovic [:milan] from comment #2)
> Any chance of a video/image of when the problem happens, as I don't see it? 
> Since it seems device specific, can you attach the about:support of the
> configuration that does have this problem?

Done. Tell me if you need something else.

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

Thanks.  Probably not the right component that I changed it to, but, I'll let :kats confirm.

Comment 7

[Emmanuel Counasse]

Attachment: another hardware (about:support)

Comment 8

[Alice0775 White]

on Windows, I filed Bug 1386117.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

(In reply to Emmanuel Counasse from comment #1)
> This is reproducible on some Windows 10 machines with GPU.

Just to be clear, did you only reproduce this on Windows? Or did you also reproduce it on Linux? The UA string in comment 0 says Linux.

Comment 10

[Emmanuel Counasse]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #9)
> (In reply to Emmanuel Counasse from comment #1)
> > This is reproducible on some Windows 10 machines with GPU.
> 
> Just to be clear, did you only reproduce this on Windows? Or did you also
> reproduce it on Linux? The UA string in comment 0 says Linux.

I did not manage to reproduce it on a Linux desktop, but I made the report from a Linux Desktop.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Thanks. In that case bug 1386117 is just a dupe of this one, I'll fold it back in.

(In reply to Alice0775 White from bug 1386117 comment 0):
> Regression window:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=26b15288e8e8b9b60de3e42bc8de3a4288dbfa35&tochange=392e
> d89ec2730a48d10b1cec741e86a242d28aa3
> 
> Triggered by:
> 392ed89ec273	David Anderson — Enable Advanced Layers on Nightly Windows 8+
> builds. (bug 1375743, r=milan)

David, can you take a look?

Comment 13

[David Anderson [:dvander] - inactive, e-mail if emergency]

The visible region on a PaintedLayer is wrong, causing transparent pixels to be interpreted as opaque. Thus the background isn't getting recomposited when it should, and everything blurs together.

Comment 14

[David Anderson [:dvander] - inactive, e-mail if emergency]

The bug is in how AL handles MayResample() on PaintedLayer. Normally when MayResample() is true the PaintedLayer is supposed to expand its visible region to be the bounds of the visible region. In the old compositor, this ran after occlusion culling, so culling used the correct region and drawing used the expanded region.

Advanced Layers is running this code *before* occlusion culling, which is not necessarily correct: the newly included pixels may not be opaque even if the opaque flag is set.

Comment 15

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: fix

This makes AL behave more like the old compositor: we use the given region during occlusion culling, but draw with the full bounds if we might resample.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/75b15c752105
Handle resampled painted layers after occlusion culling. (bug 1385961, r=mattwoodrow)

Comment 17

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/75b15c752105

Comment 18

[Emmanuel Counasse]

I can confirm that the issue is solved in at least the 57.0a (2017-08-04) Firefox Nightly. Thanks

Comment 19

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I'm confirming that bug is fixed, starting in Mozilla Firefox Nightly 57.0a1 (2017-08-03), so I'm marking this bug as VERIFIED. Thanks.