7 ms·

The question is, how do we fix this? Is there a best setting to use, and if not, who will join the working group to define one?

wmf 6y ago
It's fixed in Wayland.
- glandium 6y ago
  Is it intrinsically fixed, or is it up to the compositor to do the right thing? (implying it may be broken in some compositors)
  - BearOso 6y ago
    There's only integral buffer scales, so it's entirely up to the compositor or client to do fractional scaling. https://wayland-client-d.dpldocs.info/wayland.client.protocol.wl_surface_set_buffer_scale.html https://wayland-client-d.dpldocs.info/wayland.client.protoco...
    - glandium 6y ago
      I don't know anything about the wayland API. Does this imply that windows can't have a different scaling on each screen they may overlap on? Or can a window be split across different surfaces?
      - vetinari 6y ago
        Wayland surfaces (windows) have integer property, that says at what scale they are rendered. Compositor then suitably scales them for target displays. If a surface is at two different displays at two different resolutions, it will be scaled correctly on both (up or down; depending on the application; in practice downscaled on the lower resolution one).
  - canofbars 6y ago
    All I know is the gnome settings has a scaling section and everything respects that scale.
- KirillPanov 6y ago
  No, it's not, see my comment [1]. Wayland just punts on the issue by removing the compositor from any decision involving scaling. The "Wayland Way" is for the compoisitor to relay information (monitor-reported scale, etc) to the client, and have the client figure out how to scale itself correctly. Unfortunately this means that these HiDPI bugs have to be fixed over and over in myriad apps and toolkits, and software (cough cough chromium) that is so complicated that it cannot use a toolkit. Some compositors like sway will let you do in-compositor scaling, but this is admittedly a kludge: it produces blurry scaled-up output instead of rendering at the right resolution in the first place. The sway authors acknowledge this; the feature is only there as a "better than nothing" workaround. [1] https://news.ycombinator.com/item?id=25973875 https://news.ycombinator.com/item?id=25973875
  - badsectoracula 6y ago
    > The "Wayland Way" is for the compoisitor to relay information (monitor-reported scale, etc) to the client, and have the client figure out how to scale itself correctly. FWIW this is also the "Xorg Way" (RandR provides all the necessary information), it is just that clients do not bother. Ideally the window manager would use the information provided by RandR to set up default scale levels for each monitor and then send notifications to the applications whenever the window changes monitor to alter their scale levels (this would also allow for custom per-window scale level that is applied on top of the per-monitor scale level in case someone wants to scale up/down a specific window - e.g. scaling up some notepad-like editor for a screencast). This does require each client (and toolkit) to support arbitrary scaling... and window managers to agree on such a message, though i do remember an email about this topic being posted on Xorg mailing list some time ago. AFAIK Qt should already provide the necessary functionality for this.
    - vetinari 6y ago
      > FWIW this is also the "Xorg Way" (RandR provides all the necessary information), it is just that clients do not bother. One of the differences is, that Wayland surfaces do have scale property. So compositor knows, when clients do not bother, and can do scaling for them. Under X11, some clients do bother, some don't, and the compositor doesn't know which are which.

wmf 6y ago

It's fixed in Wayland.

glandium 6y ago
Is it intrinsically fixed, or is it up to the compositor to do the right thing? (implying it may be broken in some compositors)
- BearOso 6y ago
  There's only integral buffer scales, so it's entirely up to the compositor or client to do fractional scaling. https://wayland-client-d.dpldocs.info/wayland.client.protocol.wl_surface_set_buffer_scale.html https://wayland-client-d.dpldocs.info/wayland.client.protoco...
  - glandium 6y ago
    I don't know anything about the wayland API. Does this imply that windows can't have a different scaling on each screen they may overlap on? Or can a window be split across different surfaces?
    - vetinari 6y ago
      Wayland surfaces (windows) have integer property, that says at what scale they are rendered. Compositor then suitably scales them for target displays. If a surface is at two different displays at two different resolutions, it will be scaled correctly on both (up or down; depending on the application; in practice downscaled on the lower resolution one).
- canofbars 6y ago
  All I know is the gnome settings has a scaling section and everything respects that scale.
KirillPanov 6y ago
No, it's not, see my comment [1]. Wayland just punts on the issue by removing the compositor from any decision involving scaling. The "Wayland Way" is for the compoisitor to relay information (monitor-reported scale, etc) to the client, and have the client figure out how to scale itself correctly. Unfortunately this means that these HiDPI bugs have to be fixed over and over in myriad apps and toolkits, and software (cough cough chromium) that is so complicated that it cannot use a toolkit. Some compositors like sway will let you do in-compositor scaling, but this is admittedly a kludge: it produces blurry scaled-up output instead of rendering at the right resolution in the first place. The sway authors acknowledge this; the feature is only there as a "better than nothing" workaround. [1] https://news.ycombinator.com/item?id=25973875 https://news.ycombinator.com/item?id=25973875
- badsectoracula 6y ago
  > The "Wayland Way" is for the compoisitor to relay information (monitor-reported scale, etc) to the client, and have the client figure out how to scale itself correctly. FWIW this is also the "Xorg Way" (RandR provides all the necessary information), it is just that clients do not bother. Ideally the window manager would use the information provided by RandR to set up default scale levels for each monitor and then send notifications to the applications whenever the window changes monitor to alter their scale levels (this would also allow for custom per-window scale level that is applied on top of the per-monitor scale level in case someone wants to scale up/down a specific window - e.g. scaling up some notepad-like editor for a screencast). This does require each client (and toolkit) to support arbitrary scaling... and window managers to agree on such a message, though i do remember an email about this topic being posted on Xorg mailing list some time ago. AFAIK Qt should already provide the necessary functionality for this.
  - vetinari 6y ago
    > FWIW this is also the "Xorg Way" (RandR provides all the necessary information), it is just that clients do not bother. One of the differences is, that Wayland surfaces do have scale property. So compositor knows, when clients do not bother, and can do scaling for them. Under X11, some clients do bother, some don't, and the compositor doesn't know which are which.