What is a scaling factor of the screen?

Question

I'm reading DXGI flip model article and some parts are not clear:

• DirectFlip with panel fitters: Your window client region covers the screen, and your swapchain buffers are within some hardware-dependent scaling factor (e.g. 0.25x to 4x) of the screen. The GPU scanout hardware is used to scale your buffer while sending it to the display.

  What is this hardware-dependent scaling factor? What it does? Why?

• The traditional pattern for apps in the past has been to provide the user with a list of resolutions to choose from when the user selects exclusive fullscreen mode. With the ability of modern displays to seamlessly begin scaling content, consider providing users with the ability to choose a rendering resolution for performance scaling, independent from an output resolution, and even in windowed mode.

  I understand what they mean by the traditional pattern, it's pretty common - I'm selecting a resolution in the options screen and enjoying fullHD 800*600 picture. But I have no clue what are they describing next - displays seamlessly scaling content, resolution for performance scaling, output resolution. Could someone explain the same with simple words and examples (I bet there are already games out there that uses the technology)?

Answer 1

What they're saying is you don't have to render the game at the same resolution that it's displayed. For example you could be in a display mode of 1920×1080, but have the game rendering at only 1280×720, to run faster. The OS and display hardware can automatically upscale the frames to the display resolution under the hood.

Usually, the OS runs a window compositor, a background process that draws the desktop, all app windows, menus, etc and presents them to the display. In windowed mode, any upscaling needed would be done by the compositor. However if the game's window is covering the whole display ('borderless fullscreen') and nothing else is on top, then the OS can switch off the compositor and let the game present to the display directly.

But then if the game is at a lower resolution than the display, it still needs to be upscaled. The GPU can do this in hardware (scanout) as long as the scaling factor isn't too big. For instance, there may be a limit of 4x scaling. So, if your rendering resolution is more than 4x smaller than the display, the OS can't use the hardware upscaling and would need to keep using the window compositor instead. All of this stuff happens automatically in Windows 10, without the app needing to know about it or do anything special.

Given all this, they point out that there's no real reason for the rendering resolution of the game to be limited to the classic display modes like 800×600, 1024×768, 1280×720, etc. You might as well have a continuous resolution slider instead of a fixed set of modes. There's no problem with choosing a "weird" resolution like, say, 1000×562 or something. The upscaler/compositor will just take care of it.

This what they mean by "consider providing users with the ability to choose a rendering resolution for performance scaling, independent from an output resolution". In other words, in your game's options screen, you should give the user a slider to control rendering resolution, so they can tune it for performance vs visual quality. But it need not be tied to the actual display resolution.