[Development] Revisiting high-DPI configuration options

[Maurice Kalinowski]

> 2) Handling fractional scale factors
> 
> This is relevant for e.g. a Windows setting of 250%, corresponding to a scale
> factor of 2.5. Presenting a fractional scale factor to the app may cause
> graphics glitches, so we round it to the nearest integer, using qRound.
> 
> However, mathematically correct rounding may not be the best kind of
> correct in this case. In particular we should consider rounding factors of .5
> down instead of up. The effect would be presenting an UI that is visually
> slightly smaller than it should be, over the current behavior of presenting an
> UI that is slightly larger.
> 
> In addition we have the option of tweaking the DPI reported to the
> application to account for the remainder from the rounding.
> So for the 250% case we can report a devicePixelRatio of 2 and a DPI of 144.
> This relies on the existing DPI handling support (fonts scale automatically,
> rest of UI may not), but since the offset from the base DPI is small it might be
> OK.
> 
> Finally, we should consider adding an option to simply let the fractional scale
> factor through. We have user reports of applications that work fine with such
> factors, save for one or two bugs in Qt. These are typically custom-styled
> applications that do not rely on the Qt platform styles.
> Allowing this as an option would not mean that fractional factors are
> supported in Qt (for the formal meaning of “supported"), nor that we
> necessarily spend time on fixing related issues.
> 
[Kalinowski Maurice] 
+1 from my side. On WinRT / Windows Phone / UWP, you will hardly see an integer scale factor. That causes troubles when developers want to have native scaling and we forbid this internally.

As you mentioned, we have users who patches this part and they seem to be happy with what works then already. If painting glitches appear, we need to be sure to document why that is and what potential workarounds one could apply.

BR,
Maurice