The demo is now rendering correctly. It is crushing about 20 seconds in, but there is a separate bug - https://bugzilla.mozilla.org/show_bug.cgi?id=1522015 . This is not about visual quality any more.

1. it is better, but I still get artifacts. please re-open.
2. the WebRender crashes reported (ressource leaks) are not what bug 1522015 is about.

Just wanted to chime in here and mention that on dev channel (66.0b10 (64-bit)) w/a geforce rtx 2080ti I get massive artifacts in both the interactive and automated demos for css-fps, and the entire browser chrome periodically turns solid white. The interactive demo also causes frequent hangs. The most significant artifact is that the perspective texturing on various elements is hosed, but sometimes things flicker in and out of visibility entirely.

This appears to be true with and without WebRender, somehow? It may be that about:support is lying about what backend is being used to do layout and rasterization for the page. I checked about:support before testing and with webrender on and off I see the same artifacts.

We'll double check the behavior on Windows/GeForce. It's rather strange that you'd get the same artifacts regardless of Webrender. Are you sure it reported D3D11 compositor when you disabled WR? Did you restart the browser upon flipping that pref?

At least on my system (Ubuntu 19.04+Ivy Bridge, FF 71.0a1 (2019-09-18) (64-bit) from PPA), it no longer renders incorrectly. Still drops to about 2FPS in many parts, but now at least some parts actually render with decent FPS.

Same for me when I recently tested this on an AMD 5700 GPU - no artifacts, very smooth 60 fps in most parts, but a few places where it drops to single digit fps.

The 5700 GPU is incredibly powerful, so we must be doing something very wrong to cause those frame drops. I didn't check whether it was a CPU or GPU issue. I wonder if we hit some kind of edge case in plane-split and generate thousands of splits, or something like that. Need to investigate further to see what this remaining issue is.

Glenn, this may happen if we end up with too many draw calls, since a powerful GPU will not help with the driver overhead. Part of the reason for many draw calls could be that we have multiple batch regions per tile. Regardless, I think we should be looking at the performance in a different issue.

Clemens, could you confirm if you are still seeing the issue?

Yep - agreed we should move the performance bits to a different bug.

FWIW, I just tested again - draw call count never exceeds 200, it's often < 100 when the single FPS drops occur. Interestingly, according to the profiler, the CPU threads (backend + renderer) and GPU all remain well under 16 ms / frame. So I wonder if it's actually something else in Gecko that causes the slowdown in these parts, or perhaps something that is not being reported by the WR profiler somehow.

I can confirm, that this has been rendering correctly for a while, on both my MacBook Pro (with AMD RX 560) and Desktop (Win10 + 1070 GTX). The FPS issues of-course are still there

Retested on roughly the same config and can confirm for me that it mostly works great now and has no glitches. There are nasty frame drops later in the demo but I'm sure those are just driver / stack corner cases, so this is at least a dramatic improvement.

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Can someone close this? No one has reported any correctness issues here in a month, so things are probably fine.