1443353 - Animated transformed div fails to repaint fully, with certain NVIDIA cards & advanced layers

Status: RESOLVED WONTFIX

(Core :: Graphics: Layers, defect, P3)

Description

[guigs [:guigs] PST (please needinfo me!)]

Description of the issue: https://twitter.com/guigs_mozilla/status/959175725071851520 

A developer is animating two blocks with javascript. It renders differently on his hardware. 

Sample Code: 
https://s.codepen.io/tysonmatanich/debug/ooGYby


Hardware information:
https://pastebin.mozilla.org/9078109

NVIDIA

Comment 1

[guigs [:guigs] PST (please needinfo me!)]

To edit the information above ^
The web renderer is not available: 
Driver Date     1-23-2018
Drivers C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_7a39871618b19f06\nvldumdx.dll,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_7a39871618b19f06\nvldumdx.dll,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_7a39871618b19f06\nvldumdx.dll,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_7a39871618b19f06\nvldumdx.dll C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_7a39871618b19f06\nvldumd.dll,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_7a39871618b19f06\nvldumd.dll,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_7a39871618b19f06\nvldumd.dll,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_7a39871618b19f06\nvldumd.dll
Subsys ID       00000000
RAM     8192
Diagnostics
AzureCanvasAccelerated  0
AzureCanvasBackend      Direct2D 1.1
AzureCanvasBackend (UI Process) skia
AzureContentBackend     Direct2D 1.1
AzureContentBackend (UI Process)        skia
AzureFallbackCanvasBackend (UI Process) cairo
GPUProcessPid   97848
Decision Log
WEBRENDER       
opt-in by default: WebRender is an opt-in feature
unavailable by runtime: Build doesn't include WebRender

Comment 2

[Daniel Holbert [:dholbert]]

Here's a screenshot from the reporter on Twitter: https://pbs.twimg.com/media/DOyMXp4UIAA59DK.jpg

Good news: I can reproduce this, on Windows 10 on my ThinkPad P50. The left blue rect is only partially painted (and in sudden bursts) the first time the animation plays.

(I'm not necessarily the best person to investigate, but I'm happy to try to help if I can.)

Comment 3

[Daniel Holbert [:dholbert]]

I ran mozregression to track down when this started. It's a regression from bug 1375743

Comment 4

[Daniel Holbert [:dholbert]]

Huh -- after I finished mozregression and started Firefox with my main nightly profile, I noticed that the bug had gone away, *and* I noticed that the pref "layers.mlgpu.sanity-test-failed" showed up as being set to true. (Not sure if it was set before; I'm guessing not.)

If I toggle that pref to false (and restart Firefox), then the bug comes back.

So it does look like we're trying to proactively disable Advanced Layers for hardware that we notice is problematic, but I'm not sure how/when (and we hadn't been proactive enough to disable the issue for me when I tested in comment 2, using my normal Nightly browsing profile, which I open ~once a week in Windows on this machine).


Also: after I've toggled layers.mlgpu.sanity-test-failed to false (reintroducing the bug), I confirmed that I can fix the bug by setting layers.mlgpu.enabled to false (away from its default value of true) and restarting Firefox.

So, this is definitively a bug caused by that feature, and by our proactive "sanity-test-failed" mechanisms being apparently not quite proactive enough.

Comment 5

[Daniel Holbert [:dholbert]]

It looks like the sanity-test code here was added in bug 1377866.  CC'ing jrmuizel who was one of the people involved there.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Actually, I'm going to redirect this to Bas. He'll have a better idea about the advanced layers situation.

Comment 7

[Daniel Holbert [:dholbert]]

Now it's looking like "layers.mlgpu.sanity-test-failed" is getting set to "false" on every Firefox startup -- e.g. if I clear that pref and restart Firefox, the pref is there again and set to to "false" (indicating that the sanity test passed and we think my hardware is fine) -- and the bug reproduces (because we incorrectly think my hardware is fine).

So: maybe the Advanced Layers sanity-test is insufficiently sensitive?  It apparently was able to correctly detect an issue for me once (just before I posted comment 4), but it's not detecting that my hardware has issues now.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: about:support "graphics" section, from my affected Linux P50 machine

Here's my about:support "graphics" section, in my main browsing profile, where I can currently reproduce this bug (since the sanity-test isn't reliably failing, as noted above).

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug (mp4 format), with a page-reload near the start (which makes bug go from bad to worse)

Comment 10

[Bas Schouten (:bas.schouten)]

(In reply to Daniel Holbert [:dholbert] from comment #9)
> Created attachment 8956578 [details]
> screencast of bug (mp4 format), with a page-reload near the start (which
> makes bug go from bad to worse)

Hey Daniel, any chance you could post a video of correct rendering? It'd help having a gut feeling about what's happening here.

Comment 11

[Daniel Holbert [:dholbert]]

Sure.

Describing it verbally: basically, at any given time, the blue rectangle should have a consistent height all the way across the screen (rather than being a different height on the left half vs. right half)

Instead, when the bug reproduces, the left half of the rectangle doesn't get fully painted as it slides into view.

I'll post a screencast to demonstrate good vs. bad rendering

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug

(here's a clearer screencast of the bug, without the gratuitous reload)

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: screencast of expected rendering (notice left half of blue rect is consistent height w/ rest of the rect)

...and here's a screencast of the expected rendering (recorded in Chrome).

Comment 14

[Daniel Holbert [:dholbert]]

(The reporter confirmed on Twitter that "layers.mlgpu.sanity-test-failed=false" on his system, and that setting layers.mlgpu.enabled=false fixes the issue.  So, this seems to be either a general bug in the mlgpu/advanced-layers feature, or a hardware/driver bug that we're failing to detect in our sanity-test code.)

Comment 15

[Bas Schouten (:bas.schouten)]

(In reply to Daniel Holbert [:dholbert] from comment #14)
> (The reporter confirmed on Twitter that
> "layers.mlgpu.sanity-test-failed=false" on his system, and that setting
> layers.mlgpu.enabled=false fixes the issue.  So, this seems to be either a
> general bug in the mlgpu/advanced-layers feature, or a hardware/driver bug
> that we're failing to detect in our sanity-test code.)

All my machines have the rendering break here in similar ways, so I very much doubt the driver is at fault here. I'll have to have a look at this, I don't really know the current MLGPU code so it may take me a while to figure out.