21–30 of 264 posts
> Perhaps not the most exciting task, but I figure it’s isomorphic to any other scaling challenge And doing this for everything in the entire ecosystem of ancient GUI libraries? And dealing with the litany of different ways folks have done icons, text, and even just drawing lines onto the screen? That's where you run into a lot of trouble.
I admire your tenacity. I think folks say "X11 doesn't support DPI scaling" when they should say "most programs written against X11 to use official Xlib functionality don't understand scaling". In the article, the author uses OpenGL to make sure that they're interacting with the screen at a "lower level" than plenty of apps that were written against X. But that's the rub, I think the author neatly sidestepped by most…
So on my laptop I've been doing: xrandr --output eDP --scale 0.8x0.8 For years and years, and I never really noticed any problems with it. Guess I don't run any "bad" scale-unaware programs? Or maybe I just never noticed(?) At least from my perspective, for all practical purposes it seems to "just work".
That's probably better than most scaling done on Wayland today because it's doing the rendering directly at the target resolution instead of doing the "draw at 2x scale and then scale down" dance that was popularized by OSX and copied by Linux. If you do it that way you both lose performance and get blurry output. The only corner case a compositor needs to cover is when a client is straddling two outputs. And even in…
Earlier quoted context omitted.
This does not address anything from the article and is a (seemingly copy/pasted) generic tangent about X11.
If you'd read both the article and my post, you'd realize it does actually address the article. It's a quote from the chapter about X-Windows I wrote in the Unix Haters handbook in 1994. https://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook https://web.archive.org/web/20201120053257/http://www.simson... And a description of the screen spanning ruler app (or rather "Desk Accessory") that the Mac had around 1987 or so…
I still think X11 forwarding over SSH is a super cool and unsung/undersung feature. I know there are plenty of good reasons we don't really "do it these days" but I have had some good experiences where running the UI of a server app locally was useful. (Okay, it was more fun than useful, but it was useful.)
Earlier quoted context omitted.
If you'd read both the article and my post, you'd realize it does actually address the article. It's a quote from the chapter about X-Windows I wrote in the Unix Haters handbook in 1994. https://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook https://web.archive.org/web/20201120053257/http://www.simson... And a description of the screen spanning ruler app (or rather "Desk Accessory") that the Mac had around 1987 or so…
[flagged]
Earlier quoted context omitted.
This does not address anything from the article and is a (seemingly copy/pasted) generic tangent about X11.
If you'd read both the article and my post, you'd realize it does actually address the article. It's a quote from the chapter about X-Windows I wrote in the Unix Haters handbook in 1994. https://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook https://web.archive.org/web/20201120053257/http://www.simson... And a description of the screen spanning ruler app (or rather "Desk Accessory") that the Mac had around 1987 or so…
Apparently you have to be criticizing X11 for more than three decades now. Since you seem to know your stuff, could you please post a link to your git repository containing your personal display server that solves all the problems?
Earlier quoted context omitted.
None of the toolkits (Motif, Tk, Gtk, Qt, etc.) could handle fractional scaling so if Wayland had taken the easy way out it would break every app.
Why is Wayland trying to monkey patch something that's broken elsewhere?
That's probably better than most scaling done on Wayland today because it's doing the rendering directly at the target resolution instead of doing the "draw at 2x scale and then scale down" dance that was popularized by OSX and copied by Linux. If you do it that way you both lose performance and get blurry output. The only corner case a compositor needs to cover is when a client is straddling two outputs. And even in…
Linux does not do that.
> It's strange that Wayland didn't do it this way from the start
It did (initially for integer scale factors, later also for fractional ones, though some Wayland-based environments did it earlier downstream).
That's probably better than most scaling done on Wayland today because it's doing the rendering directly at the target resolution instead of doing the "draw at 2x scale and then scale down" dance that was popularized by OSX and copied by Linux. If you do it that way you both lose performance and get blurry output. The only corner case a compositor needs to cover is when a client is straddling two outputs. And even in…
Isn't OS X graphics supposed to be based on Display Postscript/PDF technology throughout? Why does it have to render at 2x and downsample, instead of simply rendering vector-based primitives at native resolution?