19 Nov
2025
19 Nov
'25
6:38 p.m.
- 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/teardown 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.
Yeah. Normally I'd say they should be in dxgi, and I'm still not even sure about this one. But sometimes expediency is better.
- 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.
We're already hardcoding expected outputs, aren't we?
- 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. This happens only when DXGI Debug Layer is disabled and no input is being directed to the window (moving the mouse cursor can break the optimization). 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.
Yeah, I don't think that's going to be reliably testable. At best we could add visual tests with WINETEST_INTERACTIVE.
- 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.
Sure. I don't dislike it, but I also don't see any reason we're going to need to mess with any of those parameters later.
- 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.
Perhaps it's experience. It's common in d3d to write tests like
// clear rtv // draw quad from (-0.5, -0.5 to 0.5, 0.5) // test that some/all pixels in the quad we just drew are the color we expect
I'm also a bit low on sleep, though. On a second look the grid test doesn't seem too hard to read.