<p>For PCs with discrete displays, the resampling to the screen resolution may happen either on the computer prior to the signal being sent to the display, as part of <a href="https://en.wikipedia.org/wiki/Compositing_window_manager" rel="nofollow">window compositing</a>, or on the display side. I don't think it's anything to worry about in terms of FPS, in either case, but it possibly could affect latency.</p>

<p>It depends whether you're in "true" fullscreen (exclusive) mode or not. If the app renders to a window, including a borderless fullscreen window, then the window compositor (part of the OS) will be running each frame, and any upsampling needed can happen "for free" as part of that operation. In other words, I wouldn't expect an upsample during compositing to cost noticeably more than it does to do compositing in general (which is very cheap).</p>

<p>On the other hand, if you're in true fullscreen and your app has exclusive control of the display, it's possible to set the video mode to something non-native and send your rendered image directly to the display, in which case the display's scaler chip will handle it, again without performance cost to you, since it's happening in parallel to anything going on with the GPU.</p>

<p>You mentioned Android, so I assume you're working on a mobile device. In that case, I'm not sure if there is a scaler chip, or if the mobile GPU is just expected to always output at native resolution, in which case scaling would always be done on the GPU by the compositor software. (By the way, the reason the scaling doesn't show up in profiling is likely because it's being done by the OS rather than by your app.)</p>

<p>That being said, though upscaling is very cheap, it does imply an extra pass that could increase input latency. With a borderless fullscreen window, if no other windows are visible on top of your app, and no scaling is required, the compositor could be short-circuited so that your app writes directly to the display output rather than passing through the compositor. (This is an optimization that the OS would have to perform when it detects that all the conditions are right.) Similarly, on the display, if no extra image processing is required including scaling, color correction, etc. then some stages of the display hardware might be bypassed. In either case, you could see lower latency when you render directly to native resolution than when you require scaling. This is a matter of concern for VR in particular.</p>

CC BY-SA 3.0
2016-06-24T01:28:27.813Z
2016-06-24T01:28:27.813Z
Nathan Reed
<p>This is the screen's <a href="https://en.wikipedia.org/wiki/Video_scaler" rel="nofollow">video scaler module</a>. 
Essentially, it is a dedicated piece of silicon that allows the user to use non-native screen resolutions. </p>

CC BY-SA 3.0
2016-06-23T19:38:58.193Z
2016-06-23T19:38:58.193Z
RichieSams
<p>I was under the impression that the frame buffer resolution always has to be the same as the physical screen resolution, so changing the software resolution settings would not affect rasterization. But after I made a demo and ran a profiler against it, the profiler told me that the frame buffer resolution changed according to my settings and fewer pixels were rasterized.</p>

<p>This brings up other questions I am unable to figure out. Which part of the rendering pipeline does re-sample the frame buffer to match the screen resolution? And the re-sampling stage does not show up in the profiler (Intel GPA for Android), is it so fast that I can safely ignore it or I am missing something that would cost me here?</p>

<p>Thank you.</p>

<rasterizer><hardware>
Is there a performance implication if the frame buffer resolution and the physical screen resolution are different?
Chun-Fu Chao
# Is there a performance implication if the frame buffer resolution and the physical screen resolution are different?

(Asked by: username_0 on 2016-06-23)

I was under the impression that the frame buffer resolution always has to be the same as the physical screen resolution, so changing the software resolution settings would not affect rasterization. But after I made a demo and ran a profiler against it, the profiler told me that the frame buffer resolution changed according to my settings and fewer pixels were rasterized.

This brings up other questions I am unable to figure out. Which part of the rendering pipeline does re-sample the frame buffer to match the screen resolution? And the re-sampling stage does not show up in the profiler (Intel GPA for Android), is it so fast that I can safely ignore it or I am missing something that would cost me here?

Thank you.

**Tags:** rasterizer, hardware


---

## 2 answers

### Answer by username_1 on 2016-06-24. Score: 2 | Accepted answer

For PCs with discrete displays, the resampling to the screen resolution may happen either on the computer prior to the signal being sent to the display, as part of [window compositing](https://en.wikipedia.org/wiki/Compositing_window_manager), or on the display side. I don't think it's anything to worry about in terms of FPS, in either case, but it possibly could affect latency.

It depends whether you're in "true" fullscreen (exclusive) mode or not. If the app renders to a window, including a borderless fullscreen window, then the window compositor (part of the OS) will be running each frame, and any upsampling needed can happen "for free" as part of that operation. In other words, I wouldn't expect an upsample during compositing to cost noticeably more than it does to do compositing in general (which is very cheap).

On the other hand, if you're in true fullscreen and your app has exclusive control of the display, it's possible to set the video mode to something non-native and send your rendered image directly to the display, in which case the display's scaler chip will handle it, again without performance cost to you, since it's happening in parallel to anything going on with the GPU.

You mentioned Android, so I assume you're working on a mobile device. In that case, I'm not sure if there is a scaler chip, or if the mobile GPU is just expected to always output at native resolution, in which case scaling would always be done on the GPU by the compositor software. (By the way, the reason the scaling doesn't show up in profiling is likely because it's being done by the OS rather than by your app.)

That being said, though upscaling is very cheap, it does imply an extra pass that could increase input latency. With a borderless fullscreen window, if no other windows are visible on top of your app, and no scaling is required, the compositor could be short-circuited so that your app writes directly to the display output rather than passing through the compositor. (This is an optimization that the OS would have to perform when it detects that all the conditions are right.) Similarly, on the display, if no extra image processing is required including scaling, color correction, etc. then some stages of the display hardware might be bypassed. In either case, you could see lower latency when you render directly to native resolution than when you require scaling. This is a matter of concern for VR in particular.


---

### Answer by username_2 on 2016-06-23. Score: 1

This is the screen's [video scaler module](https://en.wikipedia.org/wiki/Video_scaler).
Essentially, it is a dedicated piece of silicon that allows the user to use non-native screen resolutions.


---

