[Development] The QT_SCREEN_SCALE_FACTORS rounding problem is still annoyingly valid

Ilya Fedin fedin-ilja2010 at ya.ru
Fri Jan 27 18:04:16 CET 2023

В Fri, 27 Jan 2023 12:38:34 +0000
Morten Sørvig via Development <development at qt-project.org> пишет:

> > On 25 Jan 2023, at 14:39, Ilya Fedin <fedin-ilja2010 at ya.ru> wrote:
> > 
> > 
> > This is a follow-up to the thread I started a year ago. The fix was
> > momentally reverted back then leading to me patching Qt all that
> > time. I still get reports from users using distribution packages as
> > I obviously can't patch their Qt. The application is just unusable
> > for those users using KDE's fractional scaling. I believe another
> > attempt to fix this should be made, I've re-reported the bug as
> > https://bugreports.qt.io/browse/QTBUG-110626.  
> Thanks for following up!
> > I copied the patch I
> > proposed in the previous report, why not to take this approach?
> > Unlike https://codereview.qt-project.org/c/qt/qtbase/+/412296, it
> > doesn't change the setScreenFactor method and shouldn't lead to the
> > problems it was reverted due to.  
> That’s an interesting point, but how does it avoid the problems?
> The failing test was tst_QQmlPreview::zoom() (if I remember
> correctly), which sets a screen scale factor and then verifies by
> reading screen.devicePixelRatio. So if any rounding is applied for
> scale factors like 1.5 may cause the test to fail.
> (The test has other problems, for example macOS applies native
> scaling which will cause screen.devicePixelRatio to differ from the
> Qt scale factor, so maybe it should be rewritten as well)
> Morten

My patch doesn't modify setScreenFactor, so the rounding is applied
only to the variable value (and to the property on QScreen object, as
it's the only remaining source without rounding in
QHighDpiScaling::screenSubfactor), so the programmatic calls of
QHighDpiScaling::setScreenFactor are unaffected.

More information about the Development mailing list