3 ms·

> 1. XWayland apps (...) The Wayland compositor has no way of detecting whether it actually scales Can't X apps just set a window property (XChangeProperty) wi

• p_l 3y ago
  The toolkits would need to add that, and some of them had engineering direction incompatible with such an idea. Especially GTK 3, which was incompatible (by default) with anything that didn't resemble the imagined wayland future, including non RGBA8888 displays or systems with different GL and X11 visuals.
  • marwis 3y ago
    I don't see how any toolkit design could be incompatible with this and not sure how color spaces play into that? Every X11 app is already composited and scaled by compositor and has top-level X window where it could set any property it wishes.
    • p_l 3y ago
      Not design. Engineering direction. People problem, instead of computer problem, to be quite honest. And one of those directions was that there was no other output than blitting RGBA8888 to screen (which was at one point the only format expected to be seen with Wayland, and GTK3 already was driving towards Wayland) - potentially accelerated with OpenGL (which had hilarious results on some chips where GL pipeline was 16bit only while 2D was 24bit). Also, unless you're running Xsgi, it's not a given that every app is scaled by compositor. Honestly, the right way was always to not assume any given DPI, and instead have every top-level window be DPI-aware and have the toolkit update that information dynamically.[1] Or optionally go all-in on vector dpi-independent approach. [1] The only correct way to handle hi-dpi on Win32 GDI, where scaling is broken partly by old GDI assumption that DPI didn't change, and by applications that hardcoded 96 dpi