X.Org Could Use More Help Improving & Addressing Its Security

[pal666]

Right back at you pal (pun intended) as is evidenced by your latest comments.

you are perfect example of https://en.wikipedia.org/wiki/Dunnin...3Kruger_effect

[mdedetrich]

you are perfect example of https://en.wikipedia.org/wiki/Dunnin...3Kruger_effect

You done yet or do you want to go back to 4chan?

[oiaohm]

It have been 8 years already and scale is still integer. And I don't think fraction scaling currently available can be enabled in multi-monitor configurations anyway.

I still think that it would have been better to stick to real world sizes for UI design and let underlying system handle correct rendering using actual output's DPI.

That the thing fraction scaling is not easy todo right.

https://libredd.it/r/linux/comments/mxp8vm/fractional_scaling_on_wayland_kinda_sucks_ngl/

The most common Wayland fractional scaling exploits the means to request buffers of different interger scales. Interger scaled above the targeted fraction scaling valve.

Yes there is a method when interger scaling was added to the protocol in 2013 to produce fractional scaling that was documented it does produce good looking results but its not without its problems. The method is very heavy on memory when you are outputing like 1.25 you have a buffer at 1.25 in the compositor rendered by the compositor and buffer at 2x from the application. Interesting problem here why Xwayland looks so crap your compositor ask Xwayland for 2x buffer and it goes screw you I am only giving you a 1x buffer then most wayland compositor upscales the 2x buffer(by really basic method that 1 pixel just comes 4) then down to 1.25 and does not look too good. Yes scaling formulae most wayland compositor that support fractional scaling are using is good at down-scaling not up-scaling there are exceptions like valve gamescope that formulae is good at upscaling not so hot at downscaling.

Sway and most wlroots based does in fact support enabling fractional scaling in multi-monitor setups. Remember higher memory usage and extra processing using these modes it not going to be fun all the time.

Wayland protocol being extended to support non integer scaling does offer to reduce the memory usage and cpu overhead when/if toolkits support it.

Fractional scaling is not exactly a fun or simple problem. Particular with the issues with scaling formule normally only been good in one direction if they are good in any direction.

[tildearrow]

oiaohm Thanks for information supplementation! First, let's see what is the set buffer scale API doing:

void wl_surface_set_buffer_scale
(
wl_surface* wl_surface_
int scale
)

It is explicitly forbidding native fractional scaling by the wonderful int scale .

Second, let's see what those developers talking in the mailing list archive you linked to:

The developers are in effect saying: I like the Mac way so I forbid the Windows way. Because this way of scaling is easy to me. Screw you Hahaha.
Also "one surface spanning several non-identical monitors" is "not worth caring about".

I am one month late, but here I propose: Compatible Fractional Scaling!

Since nobody would ever scale by more than 255x, let's change int scale to float scale and read the value.
If the raw value of scale is between 00000000 and 000000FF, treat it as integer scale.
Otherwise treat it as floating point scale.
This partially keeps compatibility with old code since int and float have the same size (4 bytes).

The only problem is that old implementations may treat 1.5x as 1069547520x (3FC00000), which would most likely trigger a crash.