[d3d9] Tametsi (Steam appid 709920) launcher is rendered black
We don't really support partial presentation, see #2749. This affects all WPF apps and similar frameworks, and we have no immediate plans to really do anything about it because it's extremely cursed and simply won't work with Vulkan swap chains.
This particular issue does not really depend on partial presentation (p. 1) can also be hacked by nullifying source and dest rects. Swapeffect_copy is still needed though.
So the original behavior change happened with
https://github.com/doitsujin/dxvk/commit/609856db35c674b5b61bdfdb62fbb92baed5ca37
Before this the app looked fine when you started it and you could use it. If you moved the window it would turn black but if you then clicked a button it would turn normal again and stay that way even when the window was moved.
After this it instead starts with graphical artifacts and stay that way
Somewhere later down the line in a newer dxvk version it just turned into just being black in general. But haven't really looked much into that.
Screenshots
Yeah, that worked a bit better on some earlier dxvk versions. While the app requests partial presentation, p. 2. of the breakage is due to the partial implementation of partial presentation, i .e., if source and destination rectangles are just ignored that part of issue is not there.
Fwiw this also affects "鋼鉄戦記C21" (C21 Steel Battle Chronicles, Steam appid 1266560) launcher which uses Java.
So the original behavior change happened with 609856d
That commit also broke "Zusi", my favorite game. I added the "d3d9.noExplicitFrontBuffer" option to basically undo that commit and it works for Zusi because it prevents dxvk from swapping framebuffers on Present when there is only 1 backbuffer. Maybe it works for Tametsi and C21 Steel Battle Chronicles, too?
DLLs
awt.dllx1 2022-07
That works fine with wined3d.
I looked at that a bit and I see two issues here. Attaching PoC hack (which I am not considering to be really correct, for illustration purposes only) which lets the launcher to render normally.
poc.txt
This is java game which is using Java AWT (awt.dll) for drawing.
The game creates a swapchain with ID3DDevice9::CreateAdditionalSwapChainEx() with D3DSWAPEFFECT_COPY and BackBuffer of 1. Then, it gets the backbuffer from the swapchain just once and uses it somehow.
The game calls Present with source rect (0,0)-(557,584) and destination rectangle (-3,-22)-(554,562). It looks like nothing is ever presented with such a destination rectangle. I guess it is maybe because it violates VUID-VkDisplayPresentInfoKHR-dstRect-01258 but I didn't check in details. Adjusting the rect as in the attached patch (avoiding negative coordinates) fixes this part. That adjustment is of course incorrect for a general case but is probably correct for this case where there is no stretch, just shift.
With 1. worked around the launcher renders the first frame correctly but quickly goes black again. In fact, it renders black each other frame and another one is correct. It does a few presents one after another and settles on the unfortunate black one. It seems to me that the issue here that AWT depends on D3DSWAPEFFECT_COPY to really keep the backbuffer contents untouched on Present. Another patch of the hack workarounds that part and makes it always render notmally.