On Mon Jul 3 18:50:55 2023 +0000, Zebediah Figura wrote:
With this implementation it should be relatively easy to present with
whatever API is available, though I don't really know how the options you mention work, so maybe there is some additional complexity I'm not aware of. Sounds great :-) The "fullscreen window styles" problem (and one of the older d3d contributors can correct me on this) is basically that some applications use ddraw (and other versions?) to present to a fullscreen window, expecting the presented area to cover the whole screen, but wgl (and Vulkan) swapchains only present to the client rect. We currently get around this by changing the window styles to remove all the nonclient decorations, but that breaks some applications too. What we want is a way to present to the actual window, and part of the idea is that using D3DKMTPresent() is the architecturally correct way to do this. I don't quite know what the concerns are for dcomposition either. Zhiyi was looking at that and ran into a wall, but he probably can at least describe the problem in greater detail. There are also some thoughts about using D3DKMTPresent() to deal more efficiently with some cases where we currently have to do a GDI blit. I'm fuzzy on these details though; again Henri can explain it better.
What D3DKMTPresent() does is that it sends a command to the compositor/DWM to display contents. Since DWM is responsible for drawing the window decoration, it allows the nonclient decorations to be overwritten without affecting window styles. The complexity here is that we don't have a DWM. Implementing a DWM and making it work with the host WM is not trivial, if not impossible. Also, the window decoration is currently handled by the host system, for example, Mutter. Having D3DKMTPresent() is certainly more architecturally correct. That way, DWM can intercept these surfaces and do the composition without tearing and not worry about the surface lifetime.