Bug 1635472 - Move the displayport by 512 increments with WebRender. r=kats

Differential Revision: https://phabricator.services.mozilla.com/D73914

gfx/layers/apz/test/mochitest/helper_fixed_pos_displayport.html

@@ -58,11 +58,10 @@
     function checkFixedPosDisplayport() {
       let fixedPosDisplayport = getCurrentFixedPosDisplayport();
 
-      // First, check the size. We allow it to be 4x the size of the visual
-      // viewport, which should accommodate displayport multipliers while still
-      // being significantly smaller than the entire layout viewport at 8x zoom.
-      ok(fixedPosDisplayport.w < (vv.width * 4), "fixed-pos displayport is too wide");
-      ok(fixedPosDisplayport.h < (vv.height * 4), "fixed-pos displayport is too tall");
+      // First, check check that we don't expand the displayport to the entire layout viewport
+      // even if we are zoomed in a lot.
+      ok(fixedPosDisplayport.w < window.innerWidth, "fixed-pos displayport is too wide");
+      ok(fixedPosDisplayport.h < window.innerHeight, "fixed-pos displayport is too tall");
 
       // Now, check the position. We want it to track the visual scroll position
       // relative to the layout viewport (but not relative to the page), since

layout/base/nsLayoutUtils.cpp

@@ -854,6 +854,8 @@ static nsRect GetDisplayPortFromMarginsData(
 
   if (presShell->IsDisplayportSuppressed()) {
     alignment = ScreenSize(1, 1);
+  } else if (gfxVars::UseWebRender()) {
+    alignment = ScreenSize(512, 512);
   } else if (StaticPrefs::layers_enable_tiles_AtStartup()) {
     // Don't align to tiles if they are too large, because we could expand
     // the displayport by a lot which can take more paint time. It's a tradeoff