Linux Graphics and Variable Refresh Rate (VRR)
-
University of Toronto ☛ A peculiarity of the X Window System: Windows all the way down
One of the reasons that X has copious nested windows is that X was designed with a particular model of writing X programs in mind, and that model made everything into a (nested) window. Seriously, everything. In an old fashioned X application, windows are everywhere. Buttons are windows (or several windows if they're radio buttons or the like), text areas are windows, menu entries are each a window of their own within the window that is the menu, visible containers of things are windows (with more windows nested inside them), and so on.
-
University of Toronto ☛ An illustration of how much X cares about memory usage
In a comment on yesterday's entry talking about X's server side graphics rendering, B.Preston mentioned that another reason for this was to conserve memory. This is very true. In general, X is extremely conservative about requiring memory, sometimes to what we now consider extreme lengths, and there are specific protocol features (or limitations) related to this.
-
GamingOnLinux ☛ GNOME pulls in experimental variable refresh rate (VRR) support for GNOME 46
After years of waiting, experimental support for variable refresh rate (VRR) has landed for GNOME, and thankfully it will be in the GNOME 46 release. The GNOME 46 release is due out around March 20th as per the release schedule, but a Release Candidate was just released for testing that also includes this new VRR code.
Update
Also here:
-
GNOME 46 to Add “Variable Refresh Rate” Configure Option
GNOME 46, the default desktop for Ubuntu 24.04 and Fedora 40, will finally have the option to enable Variable Refresh Rate. Variable Refresh Rate, VRR in short, is a feature for TV, monitor, and other displays, allowing to adjust refresh rate on the fly to match the frame rate of the graphics card.