В Fri, 27 Jan 2023 12:38:34 +0000 Morten Sørvig via Development <development@qt-project.org> пишет:
> > On 25 Jan 2023, at 14:39, Ilya Fedin <fedin-ilja2...@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. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
