1. I thought that since Present is part of DXGI, it should be tested there. If someone comes in later (with the motivation to implement it for D3D12), it can be a simple additional test parameter `is_d3d12`, without change to the checking logic, only to the test setup code and RTV clearing. But I agree that these tests are currently D3D11-specific and I don't have a particular preference, so I will move them. 2. Okay, I will see what I can do. But that means hardcoding the expected outputs for the `scroll` test, since the rectangles are not uniform there? Like H264 frames.
Minor comments:
1. I considered adding tests for what is actually displayed on the screen (not just the backbuffers), but these tests would be actually flaky even on Windows: apparently there is some optimization in DXGI/DWM that causes the background _not_ to flash different colors in `grid` test on large enough grids: they only update the actually dirty rectangles, while the backbuffer correctly updates the entire thing. The window size is necessary for testing the dirty rectangles transformation from swapchain space to window client size space. Currently it can only be done manually if you insert delays or set large enough grid size. 2. I liked being able to reconfigure the parameters fast (I even used `atoi(getenv(...))`), but I see the point that for the actual upstreaming it makes sense to hardcode what doesn't change. 3. Initial motivation was to test the expected behavior with different backbuffer count and the number of grid cells: what happens when number of grid cells is equal to or exceeds the backbuffer count? It also allowed for algorithmic rectangle comparison, not hardcoding the pixel positions like what `scroll` has to do. I honestly thought that the hardcoded pixel comparisons are harder to read, because it gets harder to understand why e.g. at `(50, 30)` there is an top-left corner of the green rectangle after scroll.