Ability to render the viewer content at quarter resolution on very-high-DPI screens #2321
Conversation
facebook-github-bot
added
the
CLA Signed
| @@ -863,11 +864,25 @@ Viewer::Viewer(const Arguments& arguments) | |||
| .addOption("agent-transform-filepath") | |||
| .setHelp("agent-transform-filepath", | |||
| "Specify path to load camera transform from.") | |||
| .addOption("quarter-resolution-scaling-limit", "2.0") | |||
There was a problem hiding this comment.
I guess a more intuitive interface to expose to the command line would be a simple bool, something like "--reduce-resolution-for-high-dpi-displays". Which should probably set the scaling limit to something like 1.6 or 1.9, right?
There was a problem hiding this comment.
Alternately, at least a better description for this arg so people know how to use it.
There was a problem hiding this comment.
That's the thing, I didn't expect people to use this option :) The default behavior makes sense to me. The option is there just as a fallback, to tune when the size reduction kicks in, in rare cases such as when the desktop scaling is configured weird, or when the GPU is not powerful enough to render at full resolution, or when making screenshots and so you do want a full resolution even on a HiDPI screen.
As I understood the request, the main objective was to reduce the resolution by default on very-high-DPI displays, which is for me with 200% display scale and higher. On lower density displays with 1.5x or 1.6x scaling it looks visibly uglier (as it did on my 4K 23" screen), so there it isn't enabled, while for >=2x scaled displays you'll see the difference only if you really focus on it (as it was the case on my 4K 16" display).
There was a problem hiding this comment.
Ok, I think I understand now. quarter-resolution-scaling-limit==2.0 means "reduce resolution for very-high-DPI displays" (by which we mean Retina and other 200%+ display scales). quarter-resolution-scaling-limit==9999 would mean "don't reduce resolution, regardless of DPI". quarter-resolution-scaling-limit==1.0 would mean "always reduce resolution, regardless of DPI".
Anyway I don't think we particularly need this feature for the C++ viewer, which isn't used much any more. This is a helpful reference. At some point, @0mdc or I can port this to the HITL framework's replay-renderer, where Retina has been bothering us.
The actual content is drawn to a non-MSAA framebuffer and then blitted, so this achieves nothing at all, and prevents framebuffer content scaling during the blit.
Thus no longer assert that the source and destination sizes match, and blit with a linear filter instead. The 2x limit is configurable with --quarter-resolution-scaling-limit.
jturner65
force-pushed
the
framebuffer-downscale
branch
from
d38eaa2
to
c47bf41
Compare
Motivation and Context
Changes needed in the native viewer application and the RenderTarget to allow for rendering at a resolution that's smaller than the actual framebuffer. For simplicity halving the framebuffer width and height, thus quarter of the size, however the limit at which this switch is done is configurable, so it's also achievable on non-HiDPI displays if you pass
--quarter-resolution-scaling-limit 1to the app.It also:
dpiScaling()when getting a framebuffer-relative mouse position. The DPI scaling value is already baked into the framebuffer size at that point, thus multiplying again gives an incorrect value.See also https://cvmlp.slack.com/archives/CFN5TAUSD/p1697296903351319 for original context.
How Has This Been Tested
On my Linux box with a 4K display, 1.6875x DPI scaling and
--quarter-resolution-scaling-limit 1.6. The way the limit calculation is done it should work on a Mac as well.Types of changes