Re: [Development] The QT_SCREEN_SCALE_FACTORS rounding problem is still annoyingly valid
On Wed, 15 Feb 2023 14:19:29 + Morten Sørvig via Development wrote: > On 27 Jan 2023, at 18:04, Ilya Fedin wrote: > > > > 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. > > However, it still rounds the value when reading it, and so > tst_QQmlPreview::zoom() gets a rounded value and fails. At least > that’s what I’m seeing. > > Here’s a new attempt: round the value when applying from the env. > variable, outside of setScreenFactor() which now keeps its existing > behavior: > > https://codereview.qt-project.org/c/qt/qtbase/+/460566 > > Morten > > It seems the change has stuck in +2 state for a month as well as the fix for QT_WIDGETS_HIGHDPI_DOWNSCALE -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The QT_SCREEN_SCALE_FACTORS rounding problem is still annoyingly valid
On 27 Jan 2023, at 18:04, Ilya Fedin wrote: 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. However, it still rounds the value when reading it, and so tst_QQmlPreview::zoom() gets a rounded value and fails. At least that’s what I’m seeing. Here’s a new attempt: round the value when applying from the env. variable, outside of setScreenFactor() which now keeps its existing behavior: https://codereview.qt-project.org/c/qt/qtbase/+/460566 Morten -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The QT_SCREEN_SCALE_FACTORS rounding problem is still annoyingly valid
В Fri, 27 Jan 2023 12:38:34 + Morten Sørvig via Development пишет: > > On 25 Jan 2023, at 14:39, Ilya Fedin 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
Re: [Development] The QT_SCREEN_SCALE_FACTORS rounding problem is still annoyingly valid
> On 25 Jan 2023, at 14:39, Ilya Fedin 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 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The QT_SCREEN_SCALE_FACTORS rounding problem is still annoyingly valid
Forgot to mention: this wasn't a problem until Qt 6 as the application was using the Qt::AA_DisableHighDpiScaling that was disabling reading this variable in Qt 5. So it's kind of regression. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
