[Development] Respecting QGuiApplication::highDpiScaleFactorRoundingPolicy on Wayland
Morten Sørvig
Morten.Sorvig at qt.io
Wed Oct 2 14:50:11 CEST 2024
> On 13 Sep 2024, at 14:54, Ilya Fedin <fedin-ilja2010 at ya.ru> wrote:
>
> On Fri, 13 Sep 2024 09:20:14 +0000
> Morten Sørvig via Development <development at qt-project.org> wrote:
>
>> It looks like there are two topics here (at least?)
>>
>> - Should we expand the use of the QHighDpiScaling machinery and
>> public API to also handle QPA level DPR? So far this is only in use
>> when Qt Gui is actually applying an UI scale factor.
>>
>> Strictly speaking, the Wayland platform plugin should not use the
>> highDpiScaleFactorRoundingPolicy property: that property controls how
>> the Qt Gui UI scale factor is rounded. The Wayland platform plugin
>> provides a DPR value to Qt, not a UI scale factor.
>
> The application doesn't know that though. All it sees:
>
> - QWidget::devicePixelRatio
> - QWindow::devicePixelRatio
> - QScreen::devicePixelRatio
>
> All of them combine both Qt's scale factor and the QPA-provided one.
> The QPA one not following the policy looks like a bug from
> application perspective.
Yep, so it depends on the point of view: is the rounding API for controlling
a particular part of the Qt implementation, or for declaring application intent
with regards to support for fractional scale factors. Now made relevant by
recent changes to the Wayland platform.
I think we need the following:
1) a proposal for getting to the current state to the new state (a QTBUG Task, or
similar)
2) a consensus that we do want to expand the usage of the RoundingPolicy etc APIs
As you can see from my previous reply and replies on gerrit I’m not completely
convinced myself, but if there is a consensus in the Qt maintainer group that this
is something we want to do then let’s go ahead.
>
>> Qt for WebAssembly is another platform with fractional
>> devicePixelRatio on the QPA level. So we want to keep these two
>> platforms (and any other relevant platform) in sync with regards to
>> which settings they react to.
>
> My patches do exactly that by rounding on QHighDpiScaling level.
Good!
>
>> - How do we support applications which need DPR rounding
>>
>> The options for rounding to int DPR are:
>>
>> 1) display the UI different (incorrect) visual size, but crisp.
>> 2) display the UI at the correct visual size, downscaled.
>>
>> I think you are suggesting implementing option 1) also for "native
>> DPR” platforms?
>>
>> Here my preference is for option 2): always present the UI at the
>> correct size for the user (not doing so is confusing), downscale if
>> needed/possible.
>>
>> This ties in with the QT_WIDGETS_HIGHDPI_DOWNSCALE feature currently
>> in development for widgets.
>>
>> One challenge here is that support is somewhat fragmented if we want
>> to provide a cross-platform setting to opt out of fractional DPR by
>> downscale: Qt only supports it for hw accelerated widgets (requires
>> QT_WIDGETS_RHI), and not all platforms support it natively.
>
> There's no problem to implement both and let the app developer decide?
> As far as I understand that would be a separate API so the rounding
> policy one could be expanded without affecting the downscale one.
>
> Also, some (if not most of them?) of applications setting the
> rounding policy have their own scaling engines so the option "1)" could
> actually lead to more applications with correct size and crisp
> rendering.
>
> Moreover, one of such applications wants to improve its scaling engine
> to handle multiple monitors right now and the idea of supporting
> fractional DPR was rejected because Qt's coordinate rounding doesn't
> let implement pixel perfect result: one can't position widgets at
> fractional pixels, have widgets with fractional sizes or create QImage
> with fractional size.
I think applications which have their own scaling engine wold be quite small
subset of all Qt apps? That use case could be supported but we should keep
in mind that the majority of apps will rely on functionality provided by Qt and
the native platform.
Morten
More information about the Development
mailing list