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 outp

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