2 ms·

> and changing drawing in every app Exactly. Nobody is going to update everything what's already out there. For many things, there's not even the source, even

> and changing drawing in every app Exactly. Nobody is going to update everything what's already out there. For many things, there's not even the source, even if there was a will. There's unbelievable dragging of the feet in the Linux community, so even that will is a big question. These compositors have to play with cards they were dealt, not with cards they wish they had.

md8z 5y ago
Sadly I think you will have to accept some of those apps will just never have Windows-style DPI scaling, sorry. It's the same thing with various older apps on Windows that will just not get updated because they use Win32 API functions that are hardcoded to use integers. Maybe you could come up with some clever solution that tricks them into rendering at a different size? I'm really not sure, if you are an expert in this then please help.
- kuschku 5y ago
  Windows actually modified the old-school Win32 APIs to support DPI scaling recently, so even most WinForms apps get proper DPI scaling. It’s absolutely possible. And as mentioned, switching from dpi as int to scale-factor as int was reason enough to break all software, going back should be just as justified.
  - md8z 5y ago
    If you know the technical details of how that was done in Windows then please help get that implemented. AFAIK those win32 APIs were not changed to take floating point, so there is some other kind of heuristic or something going on there, and I expect it won't work in all cases e.g. if the application itself renders its own backing surfaces and never takes scale into account.
    - kuschku 5y ago
      AFAIK it’s not much different from e.g. Qt. As the protocol between compositor and app includes a full dpi value the toolkit can just render everything at a larger scale, with the same rounding pattern used to ensure everything still fits. Sure, some parts will be slightly offset, and any widget that first renders, requests the rendered data, and post-processes that will be slightly blurry, but it works fine. The same can be done in any environment where the protocol between toolkit and compositor contains enough metadata and applications can tell the compositor that they’re rendering at native scale. So, X11 works, Wayland won’t work until the protocol gets significantly changed. I had a similar patch for my compositor, the protocol libs, and Qt where I just let windows specify that they’re rendering at native scale, and I let Qt handle the scale factor as if QT_SCREEN_SCALE_FACTORS had been set accordingly.
      - md8z 5y ago
        If you have a working patch then I would suggest working with other developers to get a similar thing implemented elsewhere. Also I don't think this needs significant changes in the Wayland protocol at all so I'm really confused what you mean, it seems like all you need is one additional message to specify the DPI to the application. The hard part is getting this implemented everywhere.
        kuschku 5y ago
        So at first you need a way to have the compositor notify the application which dpis it should render at (because it’d be multiple). And then you’d need a way for applications to tag each buffer it renders with the DPI it’s rendered at, so the compositor can show the right buffer natively on the right screen. For performance improvements, it even makes sense to provide a clip mask telling which part of the window each DPI should be rendered for. Now, that’s complicated, but doable. I did it. What’s more complicated is handling situations where compositors don’t support this, or only support parts of it. That whole backwards compatibility part is more work than getting the whole feature built and shipped, and it’s entirely unnecessary.
        nextaccountic 5y ago
    - vetinari 5y ago
      Windows has one advantage: the display server api is private, so there's no app talking directly to window server, but everything goes through gdi32/user32. As a result, they could make some changes that Linux toolkits cannot make; and linking to gtk (or even libx11/libxcb/libwayland-client) is not mandatory in the Linux world, so they cannot fix things behind app backs. And the windows solution is not reliable either; the only reliable solution was macOS one.
kuschku 5y ago
Why was it possible to break the world to remove these things when switching from Gtk2 to Gtk3, but now it’s not possible to re-add them? Why was it possible to remove it when switching from X11 to wayland, but now it’s not possible to re-add it? I’ve complained about this since before Gtk3 and Wayland were stable, constantly warning against making these decisions, and now that the bad decisions have been made, doing another protocol break to fix them is apparently out of the question?
- vetinari 5y ago
  You don't understand. When GTK3 came, it didn't break GTK2 and GTK2 apps. They could work side-by-side, as they were before. What you suggest is either kicking out the world from beneath them, or having all of them updated, at the same time. That's not going to happen.

md8z 5y ago

Sadly I think you will have to accept some of those apps will just never have Windows-style DPI scaling, sorry. It's the same thing with various older apps on Windows that will just not get updated because they use Win32 API functions that are hardcoded to use integers. Maybe you could come up with some clever solution that tricks them into rendering at a different size? I'm really not sure, if you are an expert in this then please help.

kuschku 5y ago
Windows actually modified the old-school Win32 APIs to support DPI scaling recently, so even most WinForms apps get proper DPI scaling. It’s absolutely possible. And as mentioned, switching from dpi as int to scale-factor as int was reason enough to break all software, going back should be just as justified.
- md8z 5y ago
  If you know the technical details of how that was done in Windows then please help get that implemented. AFAIK those win32 APIs were not changed to take floating point, so there is some other kind of heuristic or something going on there, and I expect it won't work in all cases e.g. if the application itself renders its own backing surfaces and never takes scale into account.
  - kuschku 5y ago
    AFAIK it’s not much different from e.g. Qt. As the protocol between compositor and app includes a full dpi value the toolkit can just render everything at a larger scale, with the same rounding pattern used to ensure everything still fits. Sure, some parts will be slightly offset, and any widget that first renders, requests the rendered data, and post-processes that will be slightly blurry, but it works fine. The same can be done in any environment where the protocol between toolkit and compositor contains enough metadata and applications can tell the compositor that they’re rendering at native scale. So, X11 works, Wayland won’t work until the protocol gets significantly changed. I had a similar patch for my compositor, the protocol libs, and Qt where I just let windows specify that they’re rendering at native scale, and I let Qt handle the scale factor as if QT_SCREEN_SCALE_FACTORS had been set accordingly.
    - md8z 5y ago
      If you have a working patch then I would suggest working with other developers to get a similar thing implemented elsewhere. Also I don't think this needs significant changes in the Wayland protocol at all so I'm really confused what you mean, it seems like all you need is one additional message to specify the DPI to the application. The hard part is getting this implemented everywhere.
      - kuschku 5y ago
        So at first you need a way to have the compositor notify the application which dpis it should render at (because it’d be multiple). And then you’d need a way for applications to tag each buffer it renders with the DPI it’s rendered at, so the compositor can show the right buffer natively on the right screen. For performance improvements, it even makes sense to provide a clip mask telling which part of the window each DPI should be rendered for. Now, that’s complicated, but doable. I did it. What’s more complicated is handling situations where compositors don’t support this, or only support parts of it. That whole backwards compatibility part is more work than getting the whole feature built and shipped, and it’s entirely unnecessary.
        nextaccountic 5y ago
  - vetinari 5y ago
    Windows has one advantage: the display server api is private, so there's no app talking directly to window server, but everything goes through gdi32/user32. As a result, they could make some changes that Linux toolkits cannot make; and linking to gtk (or even libx11/libxcb/libwayland-client) is not mandatory in the Linux world, so they cannot fix things behind app backs. And the windows solution is not reliable either; the only reliable solution was macOS one.

kuschku 5y ago

Why was it possible to break the world to remove these things when switching from Gtk2 to Gtk3, but now it’s not possible to re-add them? Why was it possible to remove it when switching from X11 to wayland, but now it’s not possible to re-add it? I’ve complained about this since before Gtk3 and Wayland were stable, constantly warning against making these decisions, and now that the bad decisions have been made, doing another protocol break to fix them is apparently out of the question?

vetinari 5y ago
You don't understand. When GTK3 came, it didn't break GTK2 and GTK2 apps. They could work side-by-side, as they were before. What you suggest is either kicking out the world from beneath them, or having all of them updated, at the same time. That's not going to happen.