On Tue Feb 28 00:42:37 2023 +0000, Zebediah Figura wrote:
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. Wait, so it blits from the backbuffer, not the frontbuffer? Can we rely on Commit() being called every frame *before* Present(), or something? I can believe that this is how it's supposed to work, but it's more than a little surprising, and doesn't match what the documentation (or the example [1]) seems to suggest. I.e. I'd expect in general that Commit() doesn't need to be called every frame, and Present() should always update the screen with the contents of the current backbuffer. [1] https://learn.microsoft.com/en-us/windows/uwp/gaming/directx-and-xaml-intero...
It does blit from the frontbuffer. The composition swapchain must be created with DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL. So the last backbuffer is the frontbuffer, I think. That's why I use the last backbuffer the dcomp Commit() implementation. Otherwise, I will need a private interface to access the frontbuffer. The game Corgi Warlock calls Present() and then Commit() every frame. Commit() should be called every frame in DirectComposition to make it work. Please see https://learn.microsoft.com/en-us/windows/win32/directcomp/basic-concepts#tr...