The next best thing to OLED is getting cheaper

Not saying that you can't get those 8k panels LG uses - but - sending 4k USD to someone over AliExpress feels quite risky even to me. You could probably get good stuff if you put in the effort but if you're earnings decent money from your CS job (I suppose most here are, I'm still a student) then it'll probably be easier to buy OEM/brand name.

Thing is, you could glue the panel to something as people have done. I find that detestable because you can't remove the panel non-distructably. A proper enclosure can hold the panel instead of sticking to it.

Most also have 14-bit LUTs in hardware.

Your reference [2] is on the topic of Wayland, not GTK. Although the referenced page does contains 2 occurences of "GTK", after reading the context of those occurences, I am unable to find or infer anything in support of your assertion that GTK doesn't support fractional scaling.

Also, your reference [2] implies that there are two scaling factors. Specifically at the top of your ref [2] is a link to another page (issue #34), in which a participant, "Pekka Paalanen, Maintainer", writes,

>Fractional scaling is a whole another topic apart from UI scale. I want to mention it to avoid confusing the two. . . . This is different from UI scale, because it is effectively a fractional buffer scale, without changing the UI size.

The title of your ref [2] is "Add support for fractional scaling", which was written 9 months ago, at which time I was already using fractional scaling (what I mean by fractional scaling and the meaning that is relevant in the current thread of conversation) in released software (namely Gnome 40 on Fedora 34) -- which is another sign that you've incorporated information that is correct in one specific context, but you've erroneously applied it to a different context.

Skipping forward in your ref [2] by 3 sentences, we read, "The current Wayland protocol allows clients to scale their buffers by an integer scale factor" (emphasis mine).

But most of the elements -- particularly 99.9% of the text -- on a modern operating system are stored on the computer as mathematical descriptions of curves. The big exceptions to this are JPEG and PNG files (hence the interest in SVG). (Another exception is "bitmap" fonts, but IIUC the only people looking at bitmap fonts these years are techies who have specially configured their OS or their apps to use bitmap fonts.) These mathetical descriptions have no native resolution: they can be rendered cleanly at any scaling factor.

I use Gnome Settings to tell my computer how large I want things to be, then the text is rendered at that particular scaling factor. There is never any moment in which any framebuffer or rectangular region intended to be displayed on the screen is scaled (again excepting JPGs and PNGs). I know this because I have not been using a HiDPI monitor, so I can see the individual pixels in my monitor. There is no way for the text on my computer to look as good as it does if it were being rendered into a buffer, followed by that buffer's being scaled. I would be able to tell the difference. Unless you want to try to tell me that changing the text size in Terminal.app on a Mac to some size other than the default size causes text to be rendered into a buffer, then the buffer gets scaled before being shown to the user. Or when in Google Chrome, I use the "hamburger menu" to set the "Zoom" of a web site to something other than 100%, that web page is being rendered, then scaled.

Note that Google Chrome and Firefox do their own text rendering: they do not rely on the host OS to do it like most apps do. Consequently, exploring the Zoom setting in Chrome is a good way to experience what scaling on a pure-GTK3 Linux install is like, only that the scaling factor on Linux applies to everything on the screen (including the mouse cursor) whereas in Chrome it only applies to the viewport (minus the mouse cursor).

Again, IMO the people in your reference [2] are talking about a technical detail different from the detail you think they are. Maybe that detail is relevant when you have 2 monitors of different native resolutions and you drag a window from one monitor to another. But that is not the topic of conversation here. Here we are talking about users with a single monitor who because they didn't do enough research before buying the monitor, are faced with a choice of the text's being too big or too small. That can happen on MacOS, but will never happened on a pure-GTK3 Linux install. Pick whatever native resolution, monitor size or pixel density you want: the Linux install can be adjusted so that things are not too big and not too small. (And it takes only 2 seconds to switch sizes: any windows that are open when you switch automatically adapt.) Specifically, on a monitor with 1680 horizontal pixels, Gnome Settings is giving me the following choices for the scaling factor: 100%, 125%, 150%, 175%, 200%. My guess is that if my monitor had more horizontal pixels, I would get more choices.

System Preferences on a Mac (specifically the Display ("Displays"?) pane) also gives you some choices that make everything bigger or smaller, but if you don't choose the native resolution of the display, everything is very blurry -- which does not happen on a pure-GTK3 Linux install.

ADDED. you have to run the following command (once per install) to activate the "Scale" line in the Display pane of Gnome Settings:

  gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"