[Development] Wayland: getting a screen's fractional scale before the first window exists

[Ilya Fedin]

On Sat, 08 Aug 2026 01:52:50 +0000
Jamie Fitzgerald <jfitz1994 at pm.me> wrote:

> Hi Ilya,
> 
> Thanks so much for your fast and detailed response. I really
> appreciate the extra context, and the clarification about why those
> changes stalled. Waiting years for a review sounds genuinely
> disheartening, and I'm sorry that's how it went.
> 
> I'd definitely like to take you up on your offer of help. At this
> point I'm still trying to work out what direction the maintainers and
> other developers would like this to take, so I don't want to commit
> to an implementation before hearing from them. But once there's a
> clearer steer I'd very much welcome your involvement, and in the
> meantime I'll keep exploring the Qt side.
> 
> On the performance question:
> 
> > the real problem is a QImage::detach call in the RHI code
> > (QTBUG-120565)  
> 
> That's really useful to know, and I'll read through it properly. I
> think it maybe a separate issue from the one I'm chasing, though.
> QTBUG-120565 is about speed, whereas LibreOffice's main problem is
> correctness: because the integer scale is all that's available before
> the first window exists, menus, toolbars and dialogs get laid out at
> the wrong size. That's how we ended up with the original report of a
> 200% interface on a 125% display. No amount of avoiding image copies
> makes a menu the right size.

I honestly don't understand why the report has no attention for more
than two years, it's a big cross-platform pain point making widget
performance just awful once you add a Q(Rhi|OpenGL|Quick)Widget child
since Qt 6.4, I know Krita carries a patch removing that QImage::detach
call in their Qt patchset too. I don't understand why more software like
Kdenlive don't notice that. Maybe they don't do frequent update() calls
on widgets, idk.

On Sat, 08 Aug 2026 01:52:50 +0000
Jamie Fitzgerald <jfitz1994 at pm.me> wrote:

> One difference between our situations that I think strengthens the
> case for fixing this in Qt: you were able to carry your patches in
> Telegram Desktop's own Qt patchset. LibreOffice can't do that. On
> Linux we run against whatever Qt the distribution ships, so patching
> Qt ourselves isn't an option, and any workaround has to live in our
> own code instead. Applications that use the system Qt have no
> alternative here, which is really why I'd rather this were solved
> upstream than downstream.

Well, given that Qt is very slow at both fixing bugs themsevles and
reviewing third party patches, if tdesktop was doing like that, I guess
the users would have to just suffer. Maybe OpenGL code would then be
disabled on Linux by default. Anyway, I'm glad that's not the case as
patches allow to fix a lot of bugs Qt just doesn't care about and make
the UX way better.

On Sat, 08 Aug 2026 01:52:50 +0000
Jamie Fitzgerald <jfitz1994 at pm.me> wrote:

> Two things I'd genuinely value your view on:
> 
> 1. If you were starting again now, would you take the same approach
> as 590173, or would you shape it differently given what you learned
> afterwards?

I just don't see any other way to get fractional scaling support on
Wayland in tdesktop. Anything that wouldn't transaprently fix the
coordinate space and logicalDotsPerInch(), would require a major
rewrite in tdesktop.

Though, the patch has evolved over the year it was shipped. You can see
the latest version at
https://github.com/desktop-app/patches/commit/1ffcb17817a2cab167061d530703842395291e69
as well as other related patches that I haven't pushed to Qt since I
got no review even on the pushed patches.

On Sat, 08 Aug 2026 01:52:50 +0000
Jamie Fitzgerald <jfitz1994 at pm.me> wrote:

> 2. Would you be willing to add a note to the thread? I
> think two people asking for the same thing, one of whom has actually
> shipped it, reads rather differently from one newcomer asking.

Which thread? If you mean the gerrit review, I'm doubt it has much
sense, they were ignoring it anyway and read this mailing list too.

On Sat, 08 Aug 2026 01:52:50 +0000
Jamie Fitzgerald <jfitz1994 at pm.me> wrote:

> 
> Thanks again for taking the time.
> 
> Jamie
> 
> On Saturday, August 8th, 2026 at 8:57 AM, Ilya Fedin
> <fedin-ilja2010 at ya.ru> wrote:
> 
> > On Fri, 07 Aug 2026 22:34:46 +0000
> > Jamie Fitzgerald via Development <development at qt-project.org> wrote:
> >   
> > > Hi all,
> > >
> > > I work on the Qt/Wayland side of LibreOffice's VCL plugin, and I'd
> > > like to ask whether Qt could expose a screen's fractional scale
> > > before any window exists, and if so, what shape you'd want it in.
> > >  
> > 
> > Hi, I'm the author of 590173/590174.
> >   
> > > Why it's needed: LibreOffice sizes its menus, toolbars and dialogs
> > > while starting up, before it opens its first window. At that point
> > > QScreen::devicePixelRatio() returns the integer wl_output scale,
> > > so on a 220% desktop it reports 3 and the interface comes out
> > > about 1.36x too big. We currently force
> > > Qt::HighDpiScaleFactorRoundingPolicy::Round and let the compositor
> > > shrink the result, which wastes GPU work and softens everything. I
> > > have a change under review in LibreOffice (208347, tdf#172896)
> > > that reads the Wayland output directly instead, but our reviewer
> > > would rather we didn't carry Wayland specific code if Qt could
> > > provide the value, which is why I'm asking here first.
> > >
> > > I've read 563344 ("Guess output devicePixelRatio from XdgOutput
> > > geometry"), last updated June 2024, and 590173 ("Client: Get
> > > screen's fractional device pixel ratio via xdg-output"), last
> > > updated October 2024. I'm not trying to reopen those arguments. I
> > > have one case that wasn't discussed and some measurements that
> > > may have moved the picture since.
> > >
> > > The case: "use QWindow::devicePixelRatio() instead" has been the
> > > answer each time, and for most applications it's the right one. It
> > > doesn't apply here because there is no window yet. The layout
> > > happens before any surface is committed, so
> > > wp_fractional_scale_v1's preferred_scale event (Morten's question
> > > on 590173) hasn't arrived and can't.  
> > 
> > That's kind of the same problem I made the patches for. Though, the
> > application I did it for is quite worse, it queries only
> > QGuiApplication::devicePixelRatio (the highest of all screens) on
> > launch and caches various graphics for all run time. Moreover, it
> > supports only integer device pixel ratios and gets the fractional
> > part via QScreen::primaryScreen()->logicalDotsPerInch() and
> > supplies to its own scaling engine (the application is written in
> > Qt 5.3 times, way before Qt got high dpi support) so having high
> > dpi rounding policy work properly was essential for the app to look
> > properly with the fractional scaling protocol.
> >   
> > > The measurements: David's point on 590173 was that a slightly
> > > wrong scale is worse than a rounded up one. I agree, so what I'd
> > > propose is a value that is always checked, or reported as
> > > unavailable. The check is that the calculated scale, rounded up,
> > > must equal the integer wl_output scale Qt already has. Rather
> > > than assume that holds, I tested four compositors across seven
> > > output configurations. KWin was on a real 4K panel, the rest
> > > headless. In every case the calculated scale rounded up matched
> > > the integer wl_output scale:  
> > 
> > FWIW, that wasn't really a problem with my patch. It uses the
> > calculated scale only to report to the app while getting the buffer
> > size using the factor reported by the fractional scaling protocol.
> >   
> > >
> > > -
> > >
> > > KWin at 220%: calculated 2.20008, off by +0.00008
> > >
> > > -
> > >
> > > sway at 220%: calculated 2.20120, off by +0.00120
> > >
> > > -
> > >
> > > sway at 150%: calculated 1.50029, off by +0.00029
> > >
> > > -
> > >
> > > Hyprland at 240%: exact
> > >
> > > -
> > >
> > > mutter at 150%, 125% and 250%: exact in all three
> > >
> > > So the worst error anywhere was 0.0012, about 0.05%. Mutter and
> > > Hyprland only offer scales whose logical size divides evenly, so
> > > both come out exact. KWin and sway accept arbitrary scales and
> > > round the logical size, which is the entire source of the small
> > > errors above.
> > >
> > > One thing I'd particularly like checked.
> > > QWaylandScreen::geometry() works around mutter reporting a
> > > logical size equal to the native size (mutter issue 2631), which
> > > would make this calculation return 1.0. On mutter 50.3 I couldn't
> > > reproduce that: it reported 2560x1440 at 1.5, 3072x1728 at 1.25
> > > and 1536x864 at 2.5, all correctly divided. Issue 2631 says the
> > > problem only occurs when scale-monitor-framebuffer is off, and
> > > mutter 50.3 answers "Unknown experimental feature" when I try to
> > > enable it, which I read as it no longer being optional. If that's
> > > right, xdgGeometryIsBogus now only covers older mutter, and the
> > > main objection here is weaker than it was in 2024. I may be
> > > missing something and would rather be told.
> > >
> > > Limits of the above: only KWin was real hardware, the rest were
> > > headless virtual outputs. I didn't test niri, labwc, wayfire or
> > > weston. And although every compositor I tried reports the integer
> > > scale as the fractional scale rounded up, I can't find anything in
> > > the protocol requiring it, so I'm treating that as common practice
> > > rather than a guarantee.
> > >
> > > So, which would you prefer? I'm happy to write whichever you
> > > think is right:  
> > 
> > Those screen size problems wasn't the reason I abandoned the patch.
> > The only reason I abandoned that patch, as well as a bunch of other
> > pathces, was practical inability to get a review. I was waiting for
> > months and years. At some point I just surrended, abandoned them all
> > and limited myself to just reporting + carrying own patchset. You
> > could notice the last discussion on that patch was in September
> > 2024 and I abandoned it in October 2024, after a month of
> > inactivity and reviewers' discussion on what is the preferred API
> > but nothing about the patch itself and making other APIs working as
> > best as possible (which is still valuable in my opinion).
> > 
> > That exact patch's fate is that it was present in the Telegram
> > Desktop Qt patchset up until June 2025 and then I thought "why do I
> > carry it?".
> > 
> > The initial rationale was bad perofrmance on Wayland and the patch
> > improved it to some degree but then it was discovered that the real
> > problem is a QImage::detach call in the RHI code (QTBUG-120565) and
> > the patchset has a patch for that problem too. So i tried to just
> > remove it and there were no complaints.
> > 
> > It seems almost no one notices the downscaling and performance
> > problems were solved by the other patch, so be it, fine. But I can
> > continue the work if there's any interest in the patch.
> >   

btw, you lost development at qt-project.org as a recipient when answering,
I took the liberty to restore it, using "All" instead of "Reply" helped
me when it was happenning to myself (in claws-mail interface at least).