I'm not very knowledgeable in general about the subtleties of DXGI, but this looks potentially reasonable. I assume that we'll end up grabbing the window using some internal interface in IDCompositionVisual::SetContent() and then performing a GDI blit?
Please see commit_target() in https://gitlab.winehq.org/zhiyi/wine/-/commit/8d72aa74da59ccb1192fb5cb3d7986.... The whole DirectComposition branch is at https://gitlab.winehq.org/zhiyi/wine/-/tree/directcomposition. Basically, it GDI bitblts from the last backbuffer to the window DC. On Windows, it is composited by DWM. We don't have a DWM in Wine and I don't want to write platform specific code for doing composition so blitting to the window DC seems to be good enough.
I'm mildly curious about GetFullscreenState() and GetFullscreenDesc(). I'm also curious if ResizeBuffers() works.
I will add more tests for these.
It would probably be good to have a smoke test for presentation as well. I guess we don't have anything in Wine in the way of visual smoke tests, but having a regression test around to make sure that the whole process of presenting doesn't crash seems helpful. Then again, maybe you already have that planned on the dcomp side.
I only have tests for IDCompositionDevice::Commit(), the implementation of which accesses the swapchain backbuffer and does the blitting. I tried to do a visual test. But on Windows, it's composited by DWM so the window content is actually unchanged so I am unable to test the rendered content.
As for specific comments, I think the only thing that I'd mention is that in the tests, I'd just return immediately if we get DXGI_ERROR_UNSUPPORTED rather than checking it on every call.
I will change it.