Ancient X11 scaling technology

It's like the "oh no, X11 suffers from tearing video" problem that they pull out all the time. (A) I have no idea what "video tear" is and (B) I play video all the time on my crappy laptop running X11 and it seems fine for me. But can I ssh to my remote server and run emacs or another program completely transparently yet with Wayland? Nope. I do that with X11 continuously.

I've seen video tearing on X. Usually it doesn't happen, often it's hard to notice anyway; and when it did happen and was annoying, I just was missing some setting or other. No big deal.

> But can I ssh to my remote server and run emacs or another program completely transparently yet with Wayland? Nope.

Yes, you can! Waypipe came out 6 years ago. Its express purpose is to make a Wayland equivalent to ssh -X. https://gitlab.freedesktop.org/mstoeckl/waypipe/

If someone shows it to you, you'll recognize it. It's when one frame shows part of the prior frame and part of the next. It's most visible in moderate speed horizontal pans as an interruption in vertical lines in the picture.

It's nice to not have tearing. But IMO the functionality loss vs X11 isn't worth it for anything but a dedicated media playback/editing device.

I used to see it all the time on X11. I'd see it on YouTube/Firefox. I'd see it on VLC. I'd see it on MPV. Any video player, playing any fast paced video you'll see X11 struggle to keep up with drawing full frames that it'd just give up and draw half of one frame and another half of another frame and call it a day. The Intel driver luckily had an xorg.conf setting I could add to make this less of an issue -- I guess it'd turn on some internal Intel driver logic to skip frames or something else if it wasn't able to draw the entire video frame in time for display. However as soon as Debian made Wayland the default this issue 100% disappared and I no longer needed to edit a conf file to make my display work correctly. This is hands-down the singular reason I love Wayland. It just works without any faffing around as Windows, MacOS, etc has done since the mid 1990's. Wayland has achieved more in 5 years than X11 has done in the last 25 years.

So basically what you are saying is that they could have changed a default in a config file somewhere, 5 minutes of work, but instead they decided to spend hundreds (thousands?) of person-years building something new from scratch? And that's a good thing? Oof.

I assume there's a reason Intel didn't make that particular setting the default in their x11 drivers. While it certainly fixed the screen tearing issue, I presume there was some tradeoff which made some other feature worse off. Wayland however I assume is already built so it doesn't need the driver to implement some workaround to fix it, it's already designed to correctly handle video output by ensuring only the full frame is rendered every single frame.

Worst was with the discussion about Wayland having extra latency on mouse pointer movements. The explanation there was that X11 used HW pointer device that got updated as soon as there was a change but that might lead to gasp occasional pointer tearing. So better add a couple ms of latency to everything in Wayland and sample the mouse pointer position once per frame.

FWIW, I do see screen tearing on my X11 multi-monitor setup. I just don't care.

It depends on the game/application and what you are running and your distro may have enabled TearFree for you. I use Debian and it isn't enabled by default.

If I was to play Dark Souls 3 and/or Elden ring on Linux without tearfree. There is significant screen tearing and the game feels very choppy when playing.

To enable TearFree on Xorg. You typically make a new configuration file that sits in /etc/X11/xorg.conf.d/ and append to the X configuration

https://wiki.archlinux.org/title/AMDGPU#Tear_free_rendering

There are downside to this, but I would only imagine they are problems on older GPUs.

https://unix.stackexchange.com/questions/518362/whats-the-do...

I've never noticed these downsides personally and everything seems to work great.

I don't like Wayland. It still seems very buggy and I am running Debian Trixie and would prefer to keep using X11.

But IME Wayland does have higher performance on older hardware it seems than X. My old laptop could barely play Youtube with X11 (it is the video itself not YouTube being a resource hog, I checked), Wayland performance is much better.

> To summarise, the downsides are that it requires more memory, and that it reduces throughput and adds latency (except when there’s already a compositor or a vblank-synced fullscreen display).

https://unix.stackexchange.com/questions/518362/whats-the-do...

I think the extra requirements aren't a problem on modern cards. However on lower end devices e.g. the older intel iGPUs, I could see this becoming an issue.

> FWIW, I do see screen tearing on my X11 multi-monitor setup. I just don't care.

If you ever get really bored one day, and you have nothing else to do, and you're using AMD/ATi hardware, try enabling the TearFree option for your video card driver. Something like

  Section "Device"
   Identifier "AMD"
   Driver "amdgpu"
   Option "TearFree" "on"
  EndSection

in a new .conf file in '/etc/X11/xorg.conf.d' and a restart of your display server(s) should do the trick. It works fine for me, and has worked fine for like a decade or more.

> Wayland however I assume is already built so it doesn't need the driver to implement some workaround to fix it...

My money is on Wayland enabling the equivalent of this setting by default.

> I presume there was some tradeoff which...

Did you notice any problems after enabling the setting? If you didn't notice any problems, then why would you care about any hypothetical tradeoffs?

> Any video player, playing any fast paced video you'll see X11 struggle to keep up with drawing full frames that it'd just give up and draw half of one frame and another half of another frame and call it a day.

What hardware are you running on?

Among the many systems I have, I have a laptop running an Intel 945GM [0]. I don't see the behavior you're reporting even if I have it hooked up [1] to a 1080p external display. On that system, I have zero Xorg config files... it's all default settings.

I also don't see the behavior you report on any of my much more powerful systems.

[0] Integrated graphics chip released somewhere around 2006

[1] Via VGA cable!

> It's nice to not have tearing.

If you're running AMD hardware, try enabling the TearFree option. [0] I've been using this for years and years and years and it works fine.

[0] See this for a config file you could plop into place: <https://news.ycombinator.com/item?id=44375247>

> (it is the video itself not YouTube being a resource hog, I checked)

Did you check by downloading the video and playing it with a good standalone video player like mplayer, vlc, or mpv? If you didn't, then you didn't disentangle the web browser from the video playback.

> It just works without any faffing around as Windows, MacOS, etc has done since the mid 1990's.

Unless you like your applications to save your window positions. I like Firefox to be on my left monitor, and if I use Wayland I have to manually drag it there every time I start it, because Wayland, in the year 2025, still lacks this basic feature that Windows, macOS, and X11 have had for like 40 years now.

(unless I use XWayland, which magically returns all of the missing functionality, though with a tendency to break other things)

I've spent a lot of time in my career working on weird rendering issues on websites/devices. Believe me when I said "I checked", I know WTF I am talking about.

The only thing that was different was Wayland vs X11. Same browser, same browser settings, same OS and same plugins.

Maybe Wayland works without any faffing around for you, but the last time I ran it(via KDE), it completely hung my system whereas X11 worked out of the box.

And Wayland has been around for at least 15 years, btw, not 5. You'd think 15 years would be long enough to get something stable, but apparently not.

> Same browser, same browser settings, same OS and same plugins.

Neat. Did you test outside of the browser? Based on your report, it sounds like you didn't. As you must know, the renderers in web browsers are very, very complex. I suggest you test with a standalone video player before you go blaming the underlying windowing system for performance issues.

Isn't positioning windows a window manager problem? I can't see how that is an X11 vs Wayland issue except that the window managers you are using are different.

[flagged]

> But can I ssh to my remote server and run emacs or another program completely transparently yet with Wayland? Nope. I do that with X11 continuously

The problem is this usecase sucks major ass on X and has for a decade at least. It worked meh at one point, but as modern applications became more complex and X exploded in complexity it no longer makes any sense.

X is an unbelievably chatty protocol. Believe it or not, it's primarily meant to be run on a local socket, which is almost certainly memory mapped. Running it over the network has incredible latency, terrible lag spikes, and your windows will just kill themselves somewhat randomly.

There are newer remote desktop protocols which are literally just better.

Except: 1. It's Wayland-to-Wayland (which means you're much more limited to where it can run than X-to-X, where's the MacOS or Windows or BSD Wayland build?). 2. It's not integrated with ssh (X forwarding is part of the protocol). 3. You need it on both the client and the server, so you need to work out how to get it onto the server.

> You have to explain to me how it couldn't have been the window system giving me the uplift in video playback in the browser...

My instance of Firefox has been configured to use only software rendering. This YouTube video <https://www.youtube.com/watch?v=tO01J-M3g0U> runs fine in both Firefox and mpv. This YouTube video <https://www.youtube.com/watch?v=WjoplqS1u18> drops many frames when played at 8K in Firefox (making it choppy and sluggish), but zero when played at 8K in mpv.

There are a great many variables in play when playing something through a web browser. That's why I suggested you re-run the test without the web browser.

Speaking of "a great many variables"...

> The machine went to sluggish and painful to use, to being reasonably decent.

Then something seems to be wrong with your Xorg config. Whether it's the drivers, the configuration of the system, or both, I don't have enough information to know. Are you running Xorg on an ARM Apple machine? That's apparently known to work very, very poorly because Apple's graphics hardware is "special". Are you running an un-accelerated Xorg video driver (like the VESA or fbdev drivers) or are perhaps using the nouveau driver on Nvidia hardware? The former would certainly be very slow. The latter is known to work fine for some folks and work really, really poorly for others.

> I don't appreciate your snark.

It's not snark. It's an earnest request to reduce the number of moving parts to make troubleshooting easier. And (as we've discovered from further testimony) the web browser wasn't even involved in the slowness... the problem is a misconfiguration of your Xorg install. We would have discovered this if you'd run the requested test, but incidental self-report works just as well.