Google Chrome/Chromium Lands Wayland Fractional Scaling Support

[Quackdoc]

glad to see it, fractional scaling is a massively important feature, i've been endlessly putting off the migration to chrome, ill do it one day, probably to thorium

[MrCooper]

Verify that it runs natively on Wayland and not X: there are few ways of doing that, but my favorite is to run `xprop` command. Your cursor will then turn to + and will let you pick any X11 window to fetch its properties. If it doesnt, it's a Wayland window.

Neat, not as fun as the method I use though: Run xeyes and move the cursor over the window(s) in question. The eyes follow the cursor only while it's over X11 windows, not Wayland ones.

[mb_q]

Why did I emphasize down above? By scaling down, it remains sharp. Xwayland scales up, and that's exactly the reason why it is blurry.

It's not blurry, but still distorted, and this would be evident if not for HiDPI display (expect for aliasing) --- in the old days of early smartphones people were crazy about pixel perfection, especially on the Apple side, and then just forgot it in instant. Same story with font hinting.

IMHO there should be no scaling at all, apps should operate with buffers corresponding to physical pixels but respecting user-defined baseline size to have usable widget and text sizes, while actual screen DPI to get "100% zoom" right for graphics&co.

[ehansin]

I was aware of these options. I'm more intrested what is stopping developers from making Ozone platfrom "Auto" by default? There are a lot of electron applications which would auto-magickally run natively on Wayland after this (and their runtime update).

I fully agree with you here. This was more a reiteration for Zeioth who was not getting the "CLI" flags (don't know how to alter .desktop files or set these as system variables, so best I can call it!) to work and just wanted to steer him in what I think is the current right direction. Absolutely this flag should be set to "Auto" at this point, zero objections to that whatsoever! And agreed on the value it adds to Electron apps.

[Quackdoc]

It's not blurry, but still distorted, and this would be evident if not for HiDPI display (expect for aliasing) --- in the old days of early smartphones people were crazy about pixel perfection, especially on the Apple side, and then just forgot it in instant. Same story with font hinting.

IMHO there should be no scaling at all, apps should operate with buffers corresponding to physical pixels but respecting user-defined baseline size to have usable widget and text sizes, while actual screen DPI to get "100% zoom" right for graphics&co.

I'm not sure I understand right, so instead ill say this, android applications typically scale based logical pixel densities which sort of abstracts real pixel densities. these are called density independent pixels. 1 DIP = 1DPI at 160dpi and 1DIP = 4DPI at 320dpi (2x in both axis). when you pair this logical scaling over realistic scaling, AND when you use DPI aware scaling toolkits most modern applications are DPI aware on android.

you get the near perfect scaling thats common on the majority of android applications scale excellently i've tested everything from 360x360p screens against 3600x3600p screen on the same android install, changing on the logical density (360p is shockingly usable on android btw)(ofc once you push below 160density it becomes more and more rough with usability really capping out at 130 density) I did try a gba screen, but sadly that was a little too low for android to go and be usable outside of specialized apps

[agartner]

This was reverted btw: https://chromium-review.googlesource.../src/+/4365998

Revert "[Linux/Ozone/Wayland] Support fractional-scale-v1"

This reverts commit 5e6a7691b5f63df3e30173f073ae8e9f697d5228.

Reason for revert: This change completely broke Chromium Ozone/Wayland on compositors that support fractional-scale-v1.

Screenshot: https://imgur.com/a/wPbpQ0i (Note the oversized Chromium window)

[woddy]

I was aware of these options. I'm more intrested what is stopping developers from making Ozone platfrom "Auto" by default? There are a lot of electron applications which would auto-magickally run natively on Wayland after this (and their runtime update).

I don't know, but maybe some problem with some graphics cards, native wayland works fine for me, but on a low-end laptop, if I start chrome with the auto or wayland flag, I get gpu information that doesn't seem correct to me.
The first image is with xwayland flag set to default, the second image with native wayland flag set to auto.

[treba]

Come on Firefox, it's your turn now (and actually I thought it'll come sooner than this).

With chromium having reverted the CL the game is up again - here's the Firefox tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1767142

[mangeek]

I wonder when chrome will use wayland backend by default while running under wayland desktop? What exactly is a show stopper here?

I think all you've had to set for at least a few months has been this, on Ubuntu 20.04+. No command line options needed anymore.
image.png

[mangeek]

It's nice that Linux finally got features that have been on Windows for 10 years

You know what? It is! I don't understand why so many people felt strongly that we shouldn't do this stuff; it's pretty and fast.

I will say though, several Windows apps I use on the regular on my work computer still have blurry renders or are stuck at 1:1 scaling, so they're not totally out of the woods either.