5 ms·

> GTK4 doesn't support fractional scaling but I believe GTK5 might. I do not think this is current info, but otherwise might be the reason as it is an experime

> GTK4 doesn't support fractional scaling but I believe GTK5 might. I do not think this is current info, but otherwise might be the reason as it is an experimental feature. For example, you can enable fractional scaling in GNOME right now. https://www.youtube.com/watch?v=BjfZ8TSXsps https://www.youtube.com/watch?v=BjfZ8TSXsps This phoronix article shows the variable to enable it in GTK. https://www.phoronix.com/news/GTK-4.11.1 https://www.phoronix.com/news/GTK-4.11.1 Edit: added a little clarification + cited the specific bit of text I was responding to.

bitwize 3y ago
Then it really is time to pull the plug, and remove X11 support from the major toolkits and DEs.
- bandrami 3y ago
  What is this obsession people have with ripping out working code? Debian still ships support for token ring; the idea that X11 is ever "going away" really misunderstands how free software works.
  - resoluteteeth 3y ago
    There are going to be apps that only run on x11 for a long time and will need to use xwayland, so it's unlikely that linux distributions will stop distributing x11 libraries entirely. However, development of xorg is completely dead so it is pretty likely that distributions will stop support running xorg sessions in the future, and at some point xorg will likely not run on new graphics cards anymore. KDE has announced plans to discontinue support for running x11 sessions and only runs on wayland in the upcoming plasma 6 version. For now all the gui toolkits will presumably continue to support x11, but at some point, it is likely that new applications will only care about supporting wayland, and after that, it is possible that future versions of gui toolkits will stop supporting x11. Maybe "ripping out working code" is a bad thing, but at a certain point people would have to put in extra effort to ensure that x11 stays "working" and if nobody steps up to put in that effort and x11 support breaks, it won't be ripping out "working" code anymore.
    - yjftsjthsd-h 3y ago
      > development of xorg is completely dead I don't think that's true; didn't it just recently get a new maintainer who put out a bug fix release and everything?
      - bandrami 3y ago
        It's weird the certainty with which people say "wayland is the future" when that's not how free software works; nobody knows what "the future" is because it depends largely on volunteer labor (even if some FDo devs are paid, the packagers aren't for the most part and that's who actually gets the software to users).
    - bandrami 3y ago
      Xorg, possibly, but Xenocara is an X11 implementation that is currently maintained and regularly updated. The OpenBSD team says it's largely feature-complete so there won't be new big changes, but it's getting regular commits. OpenBSD is a small userbase but it's important enough in security circles that I have trouble imagining toolkit implementors will drop support simply because some people have a weird need to delete working software.
      - bitwize 3y ago
        Work has already begun to get Wayland working on OpenBSD. With the major toolkit and DE projects removing X support in upcoming releases, even Xenocara's long-term relevance is very much in doubt.
        bandrami 3y ago
        Not really. Matthieu's done some work to almost get it usable, but if there's been any talk of ever taking it out of ports and into the base system it hasn't happened on any public mailing lists. Given that xenocara is rootless and pledged there's not really a security argument for it, and there just isn't that much interest from the team, at least not that they've expressed. Also OpenBSD doesn't have Linux's weird insistence that a process somehow can't find out who owns a display, which makes a lot of Wayland's model kind of pointless on the platform.
  - bitwize 3y ago
    The X code path has to be maintained as the toolkit evolves. X is old, bletcherous code written for graphics hardware of the 80s and 90s. It's holding modern apps back. No one working on modern apps wants to maintain anything having to do with X.
    - bandrami 3y ago
      And network stacks would be simpler if they took out token ring support, too, and that doesn't happen either. An interface once shipped is basically frozen whether people like it or not. The toolkits still support DirectFB, even if it's not built by default.
vetinari 3y ago
There are two different things mixed together: - fractional scaling of the display output - app rendering at fractional scales. The first one works fine with Gtk 3 and newer; the application renders its output at nearest higher integer scale, and then the compositor downscales it to requested fractional scale (i.e. app renders at 200% and compositor downscales it to 175%). Apple does exactly this same thing (just with slightly different scales; they won't show you nice 150% or 175% for a reason; they optimize for different thing). The second one is rendering at fractional scales directly by the application; then the compositor doesn't downscale anything, just displays the buffer as it is (i.e. app renders at 175% and compositor displays it as it is). Since rendering at fractional scales is more demanding (just think about fractional mouse coordinates or how to display 1px straight line and don't get lost in the rounding errors), it took longer to materialize. It is this support that will have to wait for Gtk 5. But meanwhile, your (Gtk) apps will be displayed at fractional sizes using the first method.

bitwize 3y ago

Then it really is time to pull the plug, and remove X11 support from the major toolkits and DEs.

bandrami 3y ago
What is this obsession people have with ripping out working code? Debian still ships support for token ring; the idea that X11 is ever "going away" really misunderstands how free software works.
- resoluteteeth 3y ago
  There are going to be apps that only run on x11 for a long time and will need to use xwayland, so it's unlikely that linux distributions will stop distributing x11 libraries entirely. However, development of xorg is completely dead so it is pretty likely that distributions will stop support running xorg sessions in the future, and at some point xorg will likely not run on new graphics cards anymore. KDE has announced plans to discontinue support for running x11 sessions and only runs on wayland in the upcoming plasma 6 version. For now all the gui toolkits will presumably continue to support x11, but at some point, it is likely that new applications will only care about supporting wayland, and after that, it is possible that future versions of gui toolkits will stop supporting x11. Maybe "ripping out working code" is a bad thing, but at a certain point people would have to put in extra effort to ensure that x11 stays "working" and if nobody steps up to put in that effort and x11 support breaks, it won't be ripping out "working" code anymore.
  - yjftsjthsd-h 3y ago
    > development of xorg is completely dead I don't think that's true; didn't it just recently get a new maintainer who put out a bug fix release and everything?
    - bandrami 3y ago
      It's weird the certainty with which people say "wayland is the future" when that's not how free software works; nobody knows what "the future" is because it depends largely on volunteer labor (even if some FDo devs are paid, the packagers aren't for the most part and that's who actually gets the software to users).
  - bandrami 3y ago
    Xorg, possibly, but Xenocara is an X11 implementation that is currently maintained and regularly updated. The OpenBSD team says it's largely feature-complete so there won't be new big changes, but it's getting regular commits. OpenBSD is a small userbase but it's important enough in security circles that I have trouble imagining toolkit implementors will drop support simply because some people have a weird need to delete working software.
    - bitwize 3y ago
      Work has already begun to get Wayland working on OpenBSD. With the major toolkit and DE projects removing X support in upcoming releases, even Xenocara's long-term relevance is very much in doubt.
      - bandrami 3y ago
        Not really. Matthieu's done some work to almost get it usable, but if there's been any talk of ever taking it out of ports and into the base system it hasn't happened on any public mailing lists. Given that xenocara is rootless and pledged there's not really a security argument for it, and there just isn't that much interest from the team, at least not that they've expressed. Also OpenBSD doesn't have Linux's weird insistence that a process somehow can't find out who owns a display, which makes a lot of Wayland's model kind of pointless on the platform.
- bitwize 3y ago
  The X code path has to be maintained as the toolkit evolves. X is old, bletcherous code written for graphics hardware of the 80s and 90s. It's holding modern apps back. No one working on modern apps wants to maintain anything having to do with X.
  - bandrami 3y ago
    And network stacks would be simpler if they took out token ring support, too, and that doesn't happen either. An interface once shipped is basically frozen whether people like it or not. The toolkits still support DirectFB, even if it's not built by default.

vetinari 3y ago

There are two different things mixed together: - fractional scaling of the display output - app rendering at fractional scales. The first one works fine with Gtk 3 and newer; the application renders its output at nearest higher integer scale, and then the compositor downscales it to requested fractional scale (i.e. app renders at 200% and compositor downscales it to 175%). Apple does exactly this same thing (just with slightly different scales; they won't show you nice 150% or 175% for a reason; they optimize for different thing). The second one is rendering at fractional scales directly by the application; then the compositor doesn't downscale anything, just displays the buffer as it is (i.e. app renders at 175% and compositor displays it as it is). Since rendering at fractional scales is more demanding (just think about fractional mouse coordinates or how to display 1px straight line and don't get lost in the rounding errors), it took longer to materialize. It is this support that will have to wait for Gtk 5. But meanwhile, your (Gtk) apps will be displayed at fractional sizes using the first method.