I see flickering in Nightly 2018-09-26 Win10 Nvidia 1060, WebRender on https://codepen.io/Aux-Lux/pen/mxdbOX It's particularly noticeable when you resize the browser window RHS. Pixel-snapping the bounds in StackingContextHelper [1] fixes the issue. [1] https://searchfox.org/mozilla-central/rev/ce57be88b8aa2ad03ace1b9684cd6c361be5109f/gfx/layers/wr/StackingContextHelper.cpp#69

This fixes the flickering on https://codepen.io/Aux-Lux/pen/mxdbOX which occurs during window resize. https://treeherder.mozilla.org/#/jobs?repo=try&revision=77bff26c1910cc861e7148a37a638edf1eec6ec4

We need to understand why this fixes it. I certainly don't understand why it does. For that, we need a reduced, non-animated testcase that shows different rendering before + after so that we can make a call on whether the new rendering is the one we want. What's the meaning of the bounds of a stacking context? Last time I checked, WR treated the origin of the rect as an offset that it applied to the stacking context, and the size of the rect as a clip. I don't know whether that's still the case. Also, my guess would be that Gecko expresses all coordinate changes between stacking contexts through transforms (since that's how they are expressed in the display list), so I'd expect the origin of this bounds rectangle to always be zero. Is that the case? In that case, I'd expect the only change from rounding the bounds to be the fact that we might be clipping off a pixel at the right or bottom edge of the stacking context... so I think I must be wrong about some of this. And here's another case to consider: If you have two nested stacking contexts, each of which has bounds.x = 0.5, then the contents of the inner stacking context should be shifted by 1 compared to content outside both stacking contexts. This patch would introduce error into the accumulated offset. Assuming, of course, that the origin of the bounds rectangle is treated as an offset and that Gecko makes use of that offset.