New Wayland Protocol Proposed For Fractional Scaling

[Quackdoc]

No. Bcachefs is taking over 7 years to do what several other filesystems can already do now for example even though the developer is building off an existing project - bcache. Pipewire has been under development for over 7 years as well even though many people think it got mature quickly because it was just made the default in Fedora after a very long time of more quieter development. It is just evidence that complicated projects take time. It is not like there is a lot of commercial desktop linux usage funding it. No reason to automatically assume malice here.

I do wonder what the time in manhours would be instead of looking at it from an overall time perspective. and considering that none of them do it right, I don't mind waiting. I just can't help but wonder why it took wayland so long to work on it, it has been a massive problem for many people for a long time. there have been many people talking about it on their git too.

[sinepgib]

oiaohm , thanks for the reply but I am not referring to scaling of images or game graphics. I'm talking about text, and the vector elements of a desktop application. These will not look jagged at all when rendered at 2x scaling on a 4K monitor, in fact they will be perfectly sharp as you are using 4 pixels for every 1 pixel on a 1080p display. There are no fractions of pixels involved.

AFAICT Wayland (and thus the compositor) can't tell text from pictures, it just receives buffers. So regardless of whether the choice is right or wrong, there's not a lot you can do to make it different for text and image. Same for vector elements, etc. If the blur happens in the compositor, all it sees is a big picture. I'd rather have a setting, but I guess if it's not there it's because some people might find them overwhelming probably.

[oiaohm]

oiaohm , thanks for the reply but I am not referring to scaling of images or game graphics. I'm talking about text, and the vector elements of a desktop application. These will not look jagged at all when rendered at 2x scaling on a 4K monitor, in fact they will be perfectly sharp as you are using 4 pixels for every 1 pixel on a 1080p display. There are no fractions of pixels involved.

As sinepgib person states when the output of application gets to the compositor be it X11 or Wayland at that point the output is only a image. You cannot pick out text or vector elements of special treatment.

--Integer scaling without a blur function to smooth stuff out so to some users appears horrible jagged and hard to read.--

Said that for a reason. A person who is truly use to using 4k monitor res all the time doing 4 pixels for 1 pixel does in fact look jagged to them. Some users is critical statement.

The reality we have 3 groups of users.
1) Users who will see the interger scaling without blur as jagged so hate this . Yes 2x being 4 pixels for every pixel will look jagged to these users. Why their brain will be comparing what is on screen rendered at the 4K to what is being upscaled the miss alignment is a problem. Large percentage of these users will not see this problem any more if integer scaling with a little bit of blur is used.
2) Users who hate blur but don't in fact care about jagged.

Back in the 1980s there was studies on this yes these are two different humans both will get headaches and eye strain from using the incompatible type. This was studied on printed material back then. Screen does not change this problem. Human brain like visual consistency. Problem is each human define of visual consistency is different.

Yes there is a 3 group that is going to hate 1 and 2.

https://freetype.org/ttfautohint/doc/ttfautohint.html There is a lot of font adjustments to improve readability based on the number of pixels in fact being used to display the text. The ideal solution for text is in fact have the application render the text at 1 to 1 in pixels for output this is in fact to allow font hinting to-do its job correctly. The make example on that page yes it well and truly overscaled but it shows you how come it comes jagged. Square edges don't match text very well at all so font hinting is in fact performing font shape smoothing and that not going to be right if its not 1 to 1 pixel and not being right equals some people seeing the text as jagged.

Reality here you cannot scale applications output at the compositor without creating either blurry or jagged this is the mechanical limit. Bad part is basically personal preference if a person will put up with blurry or jagged this is why this does not have a single solution for developers and end users.

[oleid]

The thing that bothers me the most is that Wayland cannot render 2x scaling sharp for xwayland apps. This shouldn't be difficult as there are no fractions, it is integer scaling. On my 4K monitor with 200% scaling, every Wayland app is sharp, every XWayland app is blurry.

Since when does X11 support fractional scaling?
I recall you can 'zoom out' in X11 by some factor. But that's not what is proposed here. Furthermore, the Wayland extension allows scaling per application. Something like that was never possible with x11.

[bug77]

finally, this should let compositors stop doing the method of setting the resolution then downscaling. this means we can finally watch videos without upscaling then downscaling from there. or doing what I did, and changing to a different tty and either running mpv directly or using another compositor

Actually, when watching videos you don't want any scaling at all. I think you're better off changing the font DPI and let the screen run at its native resolution.

[bug77]

No. Bcachefs is taking over 7 years to do what several other filesystems can already do now for example even though the developer is building off an existing project - bcache. Pipewire has been under development for over 7 years as well even though many people think it got mature quickly because it was just made the default in Fedora after a very long time of more quieter development. It is just evidence that complicated projects take time. It is not like there is a lot of commercial desktop linux usage funding it. No reason to automatically assume malice here.

Because screen scaling is every bit as complex as a file system or a media server, right?
And I wasn't assuming malice. I was assuming indifference.

[Quackdoc]

Actually, when watching videos you don't want any scaling at all. I think you're better off changing the font DPI and let the screen run at its native resolution.

mpv will do a far better job at scaling videos then letting the monitor handle it. there are far more impressive scaling algos under MPV's belt for real time scalling, both upscaling and downscaling, FSRCNNX and SSSR shaders. even MPV's own included shaders are often better then a monitors scaling preforms.

[dec05eba]

Since when does X11 support fractional scaling?
I recall you can 'zoom out' in X11 by some factor. But that's not what is proposed here. Furthermore, the Wayland extension allows scaling per application. Something like that was never possible with x11.

He said 200%, not fractional scaling. It depends on the application, but qt and non-gtk applications support fractional scaling under x11. For 150% scaling, set Xft.dpi to 144 and to make it work in qt applications set QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough environment variable. Gtk however will ignore scaling for images unless you set GDK_SCALE, which doesn't support fractional scaling (even on wayland).

[RahulSundaram]

Because screen scaling is every bit as complex as a file system or a media server, right?
And I wasn't assuming malice. I was assuming indifference.

A display server on the whole is complex. "Fighting users" in an active action against which is why it is implies malice. Indifference is passive.

[RahulSundaram]

How does Gnome's Mutter wayland display server currently handle fractional scaling? The hidden config you currently have to enable is called

scale-monitor-framebuffer

The Wayland extension proposed here is for providing a cross desktop spec. Any specific implementation can do their own to get some real world usage which can then inform a cross desktop spec. Mutter's implementation specifically uses the closest integer scaling and then downsizes it.