Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com