11–20 of 264 posts
[flagged]
I really don't understand the X11 hate that keeps showing, it's old but it works. It shows my applications perfectly, I can do my video-editing and play games with Wine and Steam without issues.
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.
Drawing a circle is kind of cheating. The hard part of scaling is drawing UI elements like raster icons or 1px hairlines to look non-blurry.
And doing so actually using X not OpenGL.
[flagged]
This does not address anything from the article and is a (seemingly copy/pasted) generic tangent about X11.
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 specifically remember Hugh showing it to me a few months before Black Monday).
https://en.wikipedia.org/wiki/Desk_accessory
https://en.wikipedia.org/wiki/Black_Monday_(1987)
Just like the article you apparently didn't read mentioned:
>With my new knowledge, I also wrote an onscreen ruler using the shape extension. Somewhat tautological for measuring the two inch circle, but in the event anyone asks, I can now tell them my terminal line height is 1/8”, and yes, I measured.
https://humungus.tedunangst.com/r/xtoys/v/tip/f/ruler.c
Now 38 years later, is there a ruler app for X-Windows that can span multiple screens yet? Or Wayland, even? Why don't you write one!
Drawing a circle is kind of cheating. The hard part of scaling is drawing UI elements like raster icons or 1px hairlines to look non-blurry.
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 mostly using stuff that's not in "vanilla" X11. In fact, the "standard" API of X via Xlib seems to only expose functions for working in raw pixels and raw pixel coordinates without any kind of scaling awareness. See XDrawLine as an example: https://www.x.org/releases/current/doc/man/man3/XDrawLine.3....
It seems to me that the RandR extension through xrandr is the thing providing the scaling info, not X11 itself. You can see that because the author calls `XRRGetScreenResourcesCurrent()` a function that's not a part of vanilla X11 (see list of X library functions here as example: https://www.x.org/releases/current/doc/man/man3/ )
Now, xrandr has been a thing since the early 2000s hence why xrandr is ubiquitous, but due to it's nature as an extension and plenty of existing code sitting around that's totally scale-unaware, I can see why folks believe X11 is scale unaware.
Drawing a circle is kind of cheating. The hard part of scaling is drawing UI elements like raster icons or 1px hairlines to look non-blurry.
yeah, exactly. Nobody claimed that it is impossible to determin the physical geometry of your display (but that might be tricky for remote X sessions, I don't know if it would work there too?)
The author did exactly this:
> Even better, I didn’t mention that I wasn’t actually running this program on my laptop. It was running on my router in another room, but everything worked as if
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…
xrandr --output eDP --scale 0.8x0.8
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…
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.
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…
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.