Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention
В Fri, 20 May 2022 10:31:03 + Morten Sørvig пишет: > Continuing on the more pragmatic track, I’ve pushed a change to add > rounding support, along with some additional testing: > https://codereview.qt-project.org/c/qt/qtbase/+/412296 > > Morten Has the work stalled? Would be really nice to get it in 6.4 to not to live a year with this bug (personally I started experiencing it since 6.2 as DisableHighDpiScaling attribute is no-op in 6.x). ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention
On Fri, 20 May 2022 10:31:03 + Morten Sørvig wrote: > That’s fair point. The QT_ environment variables are often sharp > tools, and do make it possible to configure Qt in such a way that it > appears broken. > > I’m not sure I see what KDE could realistically change here - given > that they want to continue to set QT_SCREEN_SCALE_FACTORS, also with > fractional factors since that works for most/many apps. Did you have > a specific solution in mind? > > Continuing on the more pragmatic track, I’ve pushed a change to add > rounding support, along with some additional testing: > https://codereview.qt-project.org/c/qt/qtbase/+/412296 > > Morten Couldn't they use Xft.dpi or Xft/DPI (and maybe QT_ENABLE_HIGHDPI_SCALING=1 for Qt 5 applications) as suggested by https://doc.qt.io/qt-6/highdpi.html ? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention
On 19 May 2022, at 16:32, Ilya Fedin mailto:fedin-ilja2...@ya.ru>> wrote: On Thu, 19 May 2022 14:20:05 + Morten Sørvig mailto:morten.sor...@qt.io>> wrote: Looks inconclusive to me - no clear consensus either way. (I’m also not sure if it's a bug - it’s just "the current behavior") However, we might be able to find a way forward: the rounding policy is also under user control with the QT_SCALE_FACTOR_ROUNDING_POLICY environment variable. So users who wants no rounding at all (even for apps which claim to not support fractional scale factors) can set it to “Passthrough” to preserve the current behavior. - Morten It's a bug as it makes applications that clearly stated they don't support fractional scaling render incorrectly. The only question what's the bug: inconsistency in the QT_SCREEN_SCALE_FACTORS behavior or KDE using wrong way to set the scaling. And the lack of consensus makes it impossible to fix it on Qt side/report to KDE. :( As a result, affected applciations are unusable for a long time. That’s fair point. The QT_ environment variables are often sharp tools, and do make it possible to configure Qt in such a way that it appears broken. I’m not sure I see what KDE could realistically change here - given that they want to continue to set QT_SCREEN_SCALE_FACTORS, also with fractional factors since that works for most/many apps. Did you have a specific solution in mind? Continuing on the more pragmatic track, I’ve pushed a change to add rounding support, along with some additional testing: https://codereview.qt-project.org/c/qt/qtbase/+/412296 Morten ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention
On Thu, 19 May 2022 14:20:05 + Morten Sørvig wrote: > Looks inconclusive to me - no clear consensus either way. (I’m also > not sure if it's a bug - it’s just "the current behavior") > > However, we might be able to find a way forward: the rounding policy > is also under user control with the QT_SCALE_FACTOR_ROUNDING_POLICY > environment variable. So users who wants no rounding at all (even for > apps which claim to not support fractional scale factors) can set it > to “Passthrough” to preserve the current behavior. > > - Morten It's a bug as it makes applications that clearly stated they don't support fractional scaling render incorrectly. The only question what's the bug: inconsistency in the QT_SCREEN_SCALE_FACTORS behavior or KDE using wrong way to set the scaling. And the lack of consensus makes it impossible to fix it on Qt side/report to KDE. :( As a result, affected applciations are unusable for a long time. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention
On 17 May 2022, at 22:14, Ilya Fedin mailto:fedin-ilja2...@ya.ru>> wrote: On Tue, 10 May 2022 19:40:02 + Morten Sørvig mailto:morten.sor...@qt.io>> wrote: On 9 May 2022, at 16:47, Thiago Macieira mailto:thiago.macie...@intel.com>> wrote: On Monday, 9 May 2022 07:07:23 PDT Morten Sørvig wrote: b) In practice, QT_SCREEN_SCALE_FACTORS has become a system setting since it’s being set on behalf of the user. This means the values should be subject to rounding according to highDpiScaleFactorRoundingPolicy property, like with other system DPI settings. It it's a system setting, then one should assume it's been set to the exact value that the system wanted it to be. So if they'd wanted it rounded, they'd have rounded it. That is true, however the purpose of highDpiScaleFactorRoundingPolicy is override the system setting. For example, a Windows display can be configured for 175%, but the app knows it does not support that and has enabled rounding (to 200%). So if QT_SCREEN_SCALE_FACTORS is considered a system setting then this is an inconsistency in behavior. So, what's the decision? Is it a bug in Qt or in KDE? Looks inconclusive to me - no clear consensus either way. (I’m also not sure if it's a bug - it’s just "the current behavior") However, we might be able to find a way forward: the rounding policy is also under user control with the QT_SCALE_FACTOR_ROUNDING_POLICY environment variable. So users who wants no rounding at all (even for apps which claim to not support fractional scale factors) can set it to “Passthrough” to preserve the current behavior. - Morten ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention
On Tue, 10 May 2022 19:40:02 + Morten Sørvig wrote: > > On 9 May 2022, at 16:47, Thiago Macieira > > wrote: > > > > On Monday, 9 May 2022 07:07:23 PDT Morten Sørvig wrote: > >> b) In practice, QT_SCREEN_SCALE_FACTORS has become a system > >> setting since it’s being set on behalf of the user. This means the > >> values should be subject to rounding according to > >> highDpiScaleFactorRoundingPolicy property, like with other system > >> DPI settings. > > > > It it's a system setting, then one should assume it's been set to > > the exact value that the system wanted it to be. So if they'd > > wanted it rounded, they'd have rounded it. > > That is true, however the purpose of highDpiScaleFactorRoundingPolicy > is override the system setting. For example, a Windows display can be > configured for 175%, but the app knows it does not support that and > has enabled rounding (to 200%). > > So if QT_SCREEN_SCALE_FACTORS is considered a system setting then > this is an inconsistency in behavior. So, what's the decision? Is it a bug in Qt or in KDE? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention
> On 9 May 2022, at 16:47, Thiago Macieira wrote: > > On Monday, 9 May 2022 07:07:23 PDT Morten Sørvig wrote: >> b) In practice, QT_SCREEN_SCALE_FACTORS has become a system setting since >> it’s being set on behalf of the user. This means the values should be >> subject to rounding according to highDpiScaleFactorRoundingPolicy property, >> like with other system DPI settings. > > It it's a system setting, then one should assume it's been set to the exact > value that the system wanted it to be. So if they'd wanted it rounded, they'd > have rounded it. That is true, however the purpose of highDpiScaleFactorRoundingPolicy is override the system setting. For example, a Windows display can be configured for 175%, but the app knows it does not support that and has enabled rounding (to 200%). So if QT_SCREEN_SCALE_FACTORS is considered a system setting then this is an inconsistency in behavior. Regards, Morten ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention
On Monday, 9 May 2022 07:07:23 PDT Morten Sørvig wrote: > b) In practice, QT_SCREEN_SCALE_FACTORS has become a system setting since > it’s being set on behalf of the user. This means the values should be > subject to rounding according to highDpiScaleFactorRoundingPolicy property, > like with other system DPI settings. It it's a system setting, then one should assume it's been set to the exact value that the system wanted it to be. So if they'd wanted it rounded, they'd have rounded it. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention
On 8 May 2022, at 21:02, Ilya Fedin mailto:fedin-ilja2...@ya.ru>> wrote: 9 months has passed since the initial report and it's still in a state where it's unknown is it a bug or an intended behavior. Would be nice Thanks for the reminder! This is about the behaviour of the QT_SCREEN_SCALE_FACTORS environment variable, and if I recall correctly the current consensus there is “keep it working exactly as-is”, so the subject of changing its behavior is a good candidate for discussion on this list. In short, the issue is with how QT_SCREEN_SCALE_FACTORS and QGuiApplication::highDpiScaleFactorRoundingPolicy should interact. HighDpiScaleFactorRoundingPolicy can be set to either round fractional scale factors (1.75 -> 2), like Qt 5 does by default, or to pass them through unmodified, like Qt 6 does by default. As the bug states, QT_SCREEN_SCALE_FACTORS currently ignores this completely and there is never any rounding. The options are: a) This is intended behavior: Qt’s environment variables empowers users to override settings. If the user wants to use rounded scale factors then they can set QT_SCREEN_SCALE_FACTORS to a rounded value. b) In practice, QT_SCREEN_SCALE_FACTORS has become a system setting since it’s being set on behalf of the user. This means the values should be subject to rounding according to highDpiScaleFactorRoundingPolicy property, like with other system DPI settings. If we want to change, then we should also consider if we want to do that for 5.15.x (which I think we can, If we consider it to be a bug-fix). Regards, Morten ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
