I have a very simple DirectX 11 window, it renders correctly in windowed mode and is capable of switching to a Fullscreen Optimised (FSO) swapchain without issue. This is achieved via DXGI and setFullscreenState()
This all works great when running on a regular landscape orientation display.
Where it falls apart is on a portrait orientation display
In particular, it seems the backbuffer is being presented to the display with the width/height dimensions flipped (such that the image ends up being vertically squashed, horizontally stretched – leaving the right half the image off screen, and the bottom half the screen receiving no image)
It seems like an issue with DXGI itself from what I can see (or the documentation is incorrect)..
Specifically here
An application does not need to worry about monitor orientation, DXGI will rotate a swap-chain buffer during presentation, if necessary.
That’s pretty clear.
Of course, this additional rotation can impact performance. For best performance, take care of the rotation in your application by doing the following:
Use the DXGI_SWAP_CHAIN_FLAG_NONPREROTATED. This notifies DXGI that the application will produce a rotated image (for example, by altering its projection matrix). One thing to note, this flag is only valid while in full-screen mode.
Allocate each swap-chain buffer in its rotated size. Use IDXGIOutput::GetDesc to get these values, if necessary.
By performing the rotation in your application, DXGI will simply do a copy instead of a copy and a rotate.
This part tracks just fine. I can opt out of pre-rotation with this flag, assign the buffer sizes appropriately, and I have no further issues.
But if bothers me that the clearly documented behaviour of “does not need to worry about monitor orientation” simply does not appear to work for me.
I’ve so far only found one other person having what seems to be a similar issue, but no reports of anyone actually succeeding with this.
I’m really curious if anyone (anywhere) is in fact able to achieve a fullscreen swapchain using DXGI against a portrait oriented display
For the sake of debugging..
RenderDoc shows me exactly what I would expect to be rendered (somewhat validating that I’m using the API correctly)
While Pix shows me what looks like a landscape backbuffer instead of a portrait backbuffer, and this also demonstrates that the image is verically squashed + horizontally stretched
So.. one (or some combination) of the following seems to be at play:
- Is my code broken (which may imply the documentation is wrong)
- Is Windows 10 and/or DXGI broken (or a possible regression?)
It’s unlikely to be driver related. I have 3 displays on 2 GPUs from different vendors and I get the same results regardless of GPU)
If we take it for granted that Pix is representing the true state of the backbuffer, that probably suggests DXGI is broken
RenderDoc as I understand it just interprets my API calls, which would seem to perhaps validate that my code is in fact correct (maybe, not sure I can totally make that assertion but it’s nice to have some degree of validation)
Finally, for completeness
Raised in Microsoft Developer Community here (no surprise, not their problem)
Raised in Microsoft Feedback Hub here (not anticipating a response tbh, this channel has never yielded any interaction previously)
Raised in DirectX discord channel, folks there have confirmed my understanding that this should just work
Not sure where else to go, so here I am. I’d love to know
- Does this occur for everyone else?
- Have I glossed over anything regarding usage of DXGI?
- If this turns out to be a real bug with DXGI/DX11, is there a more reliable channel for regular people to report/confirm the issue with Microsoft’s DirectX team?
Just on terminology… I’m not talking about the classic Fullscreen Exclusive mode (FSE), but rather the Fullscreen Optimised (FSO) mode that accompanied Windows 10 – which I think is sometimes referred to as eFSE (emulated FSE)
In any case, please know that I am fully aware of the Borderless Fullscreen approach. I am aiming to support all possible flavours, and ensure that whichever the user wishes to utilise can achieve the lowest latency possible. I’m also trying not to rely on anything anecdotal and to validate latency/performance for myself