1
\$\begingroup\$

I'm using Direct3D 11 running on Windows 10 20H2, but have seen this problem going back to Windows 7.

I'm adding borderless windowed (fake fullscreen) mode support, and all of the online resources I can find suggest that it's simple: just setup a windowed mode the same size as your display resolution, use WS_POPUP, and that's all you need to do.

The problem is that it doesn't actually work.

Instead, I get (on a 1920x1080 display) a 1920x1060 window, with the bottom 20-pixel high portion of the taskbar still visible. The odd thing is, the swapchain backbuffer is sized correctly, at 1920x1080, and adding some debug output shows that my WM_SIZE message is coming through at 1920x1080; it's as if something else internal was preventing the window from covering the full screen.

Fullscreen exclusive modes work correctly.

The workflow I'm using to set this mode goes like:

  • Determine if the window will be the same size as the display.
    • If so, set WS_POPUP (not sure what to use as the ExStyle so I'm leaving it at 0 for now, but I've also tested WS_EX_TOPMOST with no success).
    • If not, set the usual array of styes.
  • Call SetWindowPos with SWP_FRAMECHANGED.
  • Pump my message loop to make sure that everything is brought up to date.
  • Call IDXGISwapChain::ResizeTarget to do the actual window resizing.
  • Respond to WM_SIZE to call IDXGISwapChain::ResizeBuffers, create my views, etc.

Of note is that I don't change the window size using SetWindowPos; I let IDXGISwapChain::ResizeTarget do that for me, and that works for every other combination of windowed-to-windowed, windowed-to-fullscreen, fullscreen-to-windowed and fullscreen-to-fullscreen transition (where "fullscreen" here is fullscreen exclusive).

The only thing that does not work is borderless windowed.

What sorcery am I missing?

\$\endgroup\$

1 Answer 1

2
\$\begingroup\$

It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.

This was, of course, all my own fault.

I had some code for centering the window after a windowed mode transition, that called SystemParametersInfo (SPI_GETWORKAREA, ... and centered the window taking account of the taskbar positioning/etc.

This was what was causing my problem.

The major clue I had was that on closer examination, a small portion of the top of my window seemed to have also been sliced off, which led me to question if it was just a problem of window positioning.

Everything works correctly now, and as a bonus I got to fix a nasty little bug I've had in code I've been using for years.

Maybe this question and it's answer will be useful to someone else who has a similar problem in the future?

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .