overlay: in D3D9's doPresent(), use swapchain's backbuffer and dimensions if drawn via IDirect3DSwapChain9::present(). #2367
Now I get the viewport thing. I'm still not understanding the swap-chain concept well enough to actually review the patch though.
My crude understanding from the MSDN doc currently is:
What I'm still wondering about is:
If you found any more decent information on d3d swap-chains that go over these issues that would also be helpful.
Apologies for the brain-dumpy nature of my reply, but here goes:
Yes, this fix is for windowed-mode Final Fantasy XIV.
Same, but I think you're right on the money.
More than one extra swap chain? I don't know.
It seems to me that this particular game, Final Fantasy XIV, does this:
When in windowed mode, only the windowed swap chain is "presented".
...If we were in situation where multiple swap chains were presented,
The FPS counter, for example, would count wrong.
The expectation is that the "screen" or "window" has just one size.
The "associated" one, that is, the one you get from ID3D9Device::GetBackBuffer() is, I believe, the back buffer of the
The IDirect3D9SwapChain type only comes into play when additional swap chains have been created.
I don't know. I suppose it's possible. (The PIP stuff.)
Though I believe you only have extra swap chains for extra windows.
To be 100% correct, we'd have to handle cases where an application draws to multiple swapchains per frame.
However, that's not feasible without some refactoring of the DevState/Pipe classes.
Right now, the assumption is one overlay per process.
At the very least, it's probably something we should try to track in the overlay.
Draws to multiple swap chains?
Not quite sure about the logic, though.
With that said, this PR is implemented with the following assumption:
Only thing I have handy is this:
Thanks for the clarifications. If you add the assumption bullet points to the patch it LGTM. As long as we manage to restrict what applications we overlay on sufficiently we don't have to be correct for every corner case but if there are assumptions having them be explicit somewhere will be handy if we ever have to revisit them.
Added the following: