(In reply to Markus Stange [:mstange] from comment #3)
(In reply to Glenn Watson [:gw] from comment #1)
Created attachment 9120387 [details]
Bug 1608741 - Fix reftest failures in DirectComposition mode with virtual surfaces.
In some cases, DC shows inaccuracies (pixel values might be off by
1 or 2) in reftests when virtual surfaces API is enabled. This is
due to the DC root visual having bilinear filtering enabled.
I wonder whether this is exacerbated by the large coordinates we use for virtual surfaces. It would be interesting to see if these artifacts happen less frequently with a smaller
For the remaining failures, do we know why these artifacts happen differently for the test and the reference? Do the two cases have different tile positions or tile opaqueness?
I think it's important to fix this rather than fuzzing it away. I would imagine that for example people who write layout reftests would be very confused if they needed to add fuzz to their test even if they use only graphics features that do not require fuzz traditionally. And worse, it would be a big waste of time if they started debugging the cause of the fuzz, only to find out that the tile content was perfectly fine but the failure was introduced at the OS compositing level.
VIRTUAL_OFFSET to a small number was the first thing I tried, and it had no effect, unfortunately (I tried 8192 and also 0). I also tried removing all the calls to
Trim which is the other virtual-surface-specific API that we use, and that had no effect either.
I suspect what is happening is that the tiles with valid pixels end up being at different locations within a surface (due to allocation patterns), and that texturing from those different UVs results in very slight inaccuracies in some cases. I suspect this because we see the exact same behavior in wrench with the texture cache on various rasterizers (we clear the texture cache between wrench tests to mitigate this).
Having said that, I totally agree that fuzzing is not desirable here. I'm going to spend another 1-2 days investigating it to try and determine the exact root cause - it might simply be that we're not correctly rounding a value passed to DC somewhere, or something like that, hopefully!