Firefox on Unix is moving away from X11-based remote control

I was talking about the flag. Qt by itself can render however you want it to, if someone wanted to make a platform abstraction that would render Qt apps with ncurses that would be possible too.

> it's basically already ready for that scenario (passing pixmaps), isn't it?

sure, if you use it as a local X11 client (or on other platforms than X11) it's what happens too

I do not have any single Gtk4+ program on my desktop, and I use a quite up-to-date rolling distribution.

Skia having a GL backend does not mean it is used. Firefox does not use it on almost any Linux platform. It still blacklists even the FOSS drivers. Tested today with upstream v93 and using radeon opensource driver.

No idea why bring VA-API into this. It is practically the same thing as XvMC with a much more generic API. It is also not necessarily Vulkan or GL. Ironically this is also one area where intelligent remoting tools win (they can send the original compressed video stream down the wire. RDP does it), where a plain H264 stream will be forced to recompress, increasing latency at best.

Cairo is also backed by X rendering and this is the default.

Basically, if I ignore the compositor and games, I do not have _any single program_ on my system which uses GL or Vulkan for 2d graphics. Not surprising: in my experience, using GL for 2D graphics (i.e. arcs, lines, etc.) usually ends up in a big slowdown -- and a big increase in memory usage and crashes. It is mostly worth only for when you do pure texture manipulation like scaling, rotating, etc. i.e. final compositing or layering.

And, if, in addition to the above, I ignore the browser, and set the corresponding Qt flag, then _all programs_ in my system render using X rendering.

Easily tested because the performance difference is abysmal when using NX.

I'm surprised by your account, and glad that you've given it. This is mine:

In high school, I was a Linux hobbyist and I also had a habit of forgetting and losing documents I needed for school. Additionally, the school's computers not completely locked down, but the selection of software on them was very limited.

So I played with a lot of remote access solutions for accessing my home desktop, both to do things on it that I couldn't do at school (like browse an uncensored web or using an IDE I couldn't install on the school computers) and to access my files or even running applications. I tested a lot of stuff, both with Windows clients and with Linux clients (but I was limited to the former at school).

I tried X2Go, TigerVNC, plain Xpra, SSH (with normal and insecure forwarding, with and without compression), NX (FreeNX on the server, but with the proprietary client alongside several open-source clients), and WinSwitch, which was some nice tooling built around Xpra. (On the LAN, I even messed around with VirtualGL for 3D acceleration with remote applications.)

Xpra was the preferred choice, and WinSwitch using Xpra and H.264 encoding worked best for me when I was away from home. Using plain X forwarding, I noticed that some applications were painfully laggy, especially Eclipse and Firefox. But even with my modest home internet connection (with especially low bandwidth on the uplink), the H.264-based solutions were very usable for any application I threw at them.

> But also just ask anyone who has used RDP versus something like VNC.

For connecting to full desktop sessions, I remember tigervnc being way faster than x11rdp.

I'm not sure I follow. While VNC and RDP are very different protocols, they ultimately both work by sending bitmaps of the server screen to the client.

Recent versions of RDP use H264 encoding, under the name "RemoteFX". I believe commercial VNC implementations do the same, although the free ones seem to be sticking with their own encoding schemes, as they believe they're better optimized for desktop content, but they're both still streaming bitmaps.

In any event, like others have mentioned, X11 forwarding has degraded over time to the point I only use it when working with locally hosted VMs. While old X software works well with it (xterm, motif toolkit stuff, things directly using xlib/xcb) modern applications like web browsers and the newer Qt/GTK libraries just don't handle latency well at all. They may be sending vector operations, but they're sending tons of small vector operations, which TCP overhead and network latency really hurts. And applications using libraries like Skia (which includes LibreOffice) are doing local rendering and just pushing bitmaps out.

I think X forwarding is conceptually better, but only if applications are really using X idiomatically, which they aren't.

I believe it's possible with the older X multihead method, Zaphod mode, to have fully separate X11 screens, which could have different DPIs on each screen. The problem is there's no way to move windows from one screen to the next, and my understanding is that is an architectural limitation of X.