This seems very useful. 👍

Thanks for proposing this! We thought of something like this for some time already.

I do have some problem with the implementation:

• I think having a float slider is not adequate. I prefer having a rounded multiplier list (Original resolution, Half Resolution, Quarter Resolution) to avoid some weird cases and strange interpolation when upscalling.
• I think that we should do that at a higher level and reduce the size of the whole GPUViewport. This would be less intrusive for draw engines and would benefit all fullscreen passes. Also this would avoid the cost of a fullscreen depth pass.

This however does introduce problems due to UI scalling and fullscreen coordinate for UI elements. One way we could avoid these issues is to create another framebuffer with native resolution and blit / resolve the lower resolution framebuffer after the drawing of all the draw engines but before the UI elements (gizmos etc...). The downside is that it would use quite a bit more Vram. These changes would be isolated to the Draw manager.

@Clément Foucault (fclem) Thank you for the review! And sorry for the delay...

In D4580#104278, @Clément Foucault (fclem) wrote:

• I think having a float slider is not adequate. I prefer having a rounded multiplier list (Original resolution, Half Resolution, Quarter Resolution) to avoid some weird cases and strange interpolation when upscalling.

I think by "strange interpolation" you meant the dirty aliasing artifact with non-integral scaling like the following photoshopped image:

In addition, fractional scaling factor provides users with more performance trade-offs to explore. The number of pixels shaded is quadratically proportional to the scaling factor. There is so huge difference in performance between original resolution and quarter resolution compared to their respective perceived quality and users should be given freedom of choosing an arbitrary point (not just from three predetermined points).

• I think that we should do that at a higher level and reduce the size of the whole GPUViewport. This would be less intrusive for draw engines and would benefit all fullscreen passes. Also this would avoid the cost of a fullscreen depth pass.

This however does introduce problems due to UI scalling and fullscreen coordinate for UI elements. One way we could avoid these issues is to create another framebuffer with native resolution and blit / resolve the lower resolution framebuffer after the drawing of all the draw engines but before the UI elements (gizmos etc...). The downside is that it would use quite a bit more Vram. These changes would be isolated to the Draw manager.

Personally, I don't like other fullscreen passes to be affected by scaling for various reasons:

• Overlay passes have much lower per-pixel rendering cost and don't benefit much from resolution reduction.
• Overlay passes often include thin lines that would lose crispness and information density when downscaled.
  • This is especially problematic for low-end GPUs such as Intel HD Graphics series because the scale has to be lowered significantly.
• Using nearest-neighbor upsampling preserves crispness, but then the quality of fractional scaling would be atrocious as described before.
• Feature parity with Cycles' viewport resolution reduction.