Why on the whey is X11 so inefficient? (little rant)

[legacy]

so, you have a SBC Linux board in a machine inside your rack, you have connected to it, and set compression_enabled=yes (of course yes) in the sshd config file, as well as you have exported the DISPLAY to your x11 client (mobaXterm on Windows)

Code: [Select]

export DISPLAY=192.168.1.12:0.0

then you launch Firefox, it points to Apple dot com ( I don't know why it happened, but it's irrelevant ) and ... here you can enjoy the fresh and genuine frustration at observing that X11 is so inefficient with big-bitmap stuff 


Ok, digging under the hood, makes you learn that the X11 protocol was never meant to handle bitmaps intensive operations (oh, and modern websites really need to have a ton of them), rather back in the day when X11 was first designed computer graphics were a lot simpler than they are today.

But who on Earth wants static text and static little pics in static HTML?!?!?

A webpage is considered shitty, poor, and ridiculous if it doesn't come with billion of animated junk around, but this is not OK for X11 since it doesn't send the screen to your computer, rather it sends the display-instructions so the X-server on your local computer can re-create the screen on your local system. And this needs to be done on each change and refresh of the display. Hence your computer receives a stream of instructions like "draw line in this color from coordinates x,y to (re.x,re.y), draw rectangle W pixels wide, H pixels high with upper-left corner at (x,y), etc."


Does it make sense? No? And!!! the solution to this is ? 


... X2GO? X12? X13? 


The protocol provided by SUN/Oracle was embedded within the SunRay-line, and it was called "Sun Global Desktop" (SGD), that uses both lossy compression to reduce the bandwidth requirements and a differential algorithm and caching to reduce the number of back-and-forth information passing that creates the high latency


Excellent, the performance on a remote machine was almost the same as an on a local machine.

But it was a commercial epic failure 

Whereas we are all good boys and girls, and on Xmas we still find a new version of the inefficient X11 under the tree; no matter if it's becoming more inefficient year after year.

Looking at alternatives, well ... if SGD is pretty dead and pretty closed-source, RDP is for Microsoft, and there are incompatibilities between WindowsXP and Windows10; but there is also a little-boy called "VNC" that sounds like the only good open source solution, and the main useful thing would be VNC-like copyrect functionality, where the server says "move this entire region of the screen up five pixels and draw five new lines of pixels under it"

Good, excellent, I like it! It might save the world, the universe, whatever. Thus I am wondering: has anyone already tried to create a hybrid solution for Linux?

'cause it's so nice and pretty, but the truly ideal option would be a custom solution that remotely displays compressed Windows (or a part of their body, e.g. compressed large bitmap from that shitty flash-technology), not the entire display 

[hendorog]

NX is a high performance layer over X.

For me the number of round trips is the performance problem with X. NX solves that nicely.

https://www.nomachine.com/

[llkiwi2006]

X11's network protocol was designed 30 years ago, clearly not to handle the rendering requirements of today's desktop. These days on the linux desktop applications draw to shared memory, and the graphics intensive ones draw with opengl directly to the gpu. With compositors and everything the xserver doesn't do that much really.

If you want remote access, just install a vnc server (like tigervnc) and enjoy remote desktop that doesn't suck.

Using a outdated and unsuitable protocol and bitching about it when alternatives are widely available is the real here.

[ataradov]

If it was up to me, I would just kill X11 network transparency to prevent rants like this. It was nice when it was designed, then things changed. Just assume that it is not there for any practical applications.

[thermistor-guy]

so, you have a SBC Linux board in a machine inside your rack, you have connected to it, and set compression_enabled=yes (of course yes) in the sshd config file, as well as you have exported the DISPLAY to your x11 client (mobaXterm on Windows)...

There could be an issue with your X server (mobaXterm) on the Windows machine.

You could try installing Cygwin plus its X server, and compare the Cygwin setup with mobaXterm setup using x11perf:
https://www.x.org/releases/X11R7.5/doc/man/man1/x11perf.1.html

If your Windows machine is on the same local network as the SBC, you should get ok (but not great) performance from Cygwin.

[legacy]

You could try installing Cygwin plus its X server, and compare the Cygwin setup with mobaXterm

I have mobaxterm professional edition, it's about the 20% faster than the demo version. Anyway, I have also a second Intel x86 laptop loaded with Linux. But it doesn't make the difference with the SBC Linux card. The performance with

- geany
- nedit
- xterm

are more than acceptable, whereas the performance with a browser like Firefox opened on apple dot com is ... too slow.

If your Windows machine is on the same local network as the SBC

yes, the SBC card and the "x terminal" (Windows laptop with mobaxterm, or Linux laptop with a current version of Xorg/X11) are on the same subnet.

oh, about that:
- the SBC card is 100Mbit/s
- the router between the SBC card and the "x terminal" is 1000Mbit/sec
- the "x terminal" is 1000Mbit/sec

I really see to many connections (packets) and requests from the SBC to the "x terminal".

[legacy]

Besides, those guys (who asked me to do so) need to have a working clipboard with all the copy&paste stuff. Can't just "grab" the framebuffer at the lowest layer (pixel), compress it (with a decent ratio >> 1:2), and shoot it to the receiver like if it was an MPEG-streaming ... 

[legacy]

that will be my default-answer - can't be done, can't be done, can't be done, don't look at me, you see me but I will leave as soon as I finish my coffee - when a friend asks me to support a project for IRIX, AIX, these EOL UNIX(1), or when a customer asks me for a technical advice on a new product made on a modern SBC Linux board that he wishes to develop with a weird remote control of the graphical stuff.

Just assume that it is not there for any practical applications.

The funny part is that Firefox was just a "testing application" of what my customer asked me to support 


(1) so, it doesn't clearly make sense for business, and for sure there are better solutions, some are not open source, and use protocols similar to SGD, but bitching with X11 might still make sense for hobbyists, e.g. because you can't compile a modern version of Firefox on IRIX because it requires a modern compiler and the GCC support was removed after 4.7.1, therefore the idea of putting the browser into an SBC Linux board, and then exporting the DISPLAY into IRIX. AIX has a similar story on its shoulders.

[guenthert]

Well, it's not entirely clear to me, why one would want to run a desktop GUI application on a remote SBC or why everyone is bitching about X11's performance today, when it was entirely usable (perhaps not great, but usable) 25 years ago (given that the network is now a hundred times, the CPUs a thousand times faster).

Rather then solving a (perceived or real) performance issue, I needed in the past a solution for the session management (the aforementioned beloved SunRays sadly weren't an option anymore after the Oracle takeover and subsequent killing of that product line).  I had some luck with X2GO (*if* one managed to find *good* matching versions of Windows and  X2GO): https://wiki.x2go.org/doku.php

In my last job I used VNC (again) and it performed actually surprisingly well now (not sure if the technology improved or whether CPUs and network are now just so fast that the brute-force approach is good enough).

[guenthert]

If it was up to me, I would just kill X11 network transparency to prevent rants like this. It was nice when it was designed, then things changed. Just assume that it is not there for any practical applications.

They did.  On Ubuntu systems (for a number of years now) the X server is started with the -nolisten option by default.  Utterly frustrating if you actually *do* want to make a remote connection.

[legacy]

Utterly frustrating if you actually *do* want to make a remote connection.

remote connections to X11 are also subjected to security defects, the reason why there are tools like "xhost" and tons of other "smart" (sarc) workarounds.

X11 tunneled into ssh is more interesting, it doesn't use the standard x11 listening port, and it's safer but /usr/sbin/sshd needs to be configured with "X11-forwarding=yes", and "compression_enabled=yes"

enabling compression reduces the bandwidth, but this helps with applications like { nedit, geany, xterm }; it doesn't help with applications like firefox on high-intensity bitmap requests due to the high traffic it makes in term of the number of packets to be sent and served.

In short, it makes those packets smaller in size, but it doesn't reduce their number.

[dmills]

I actually used X11s network transparency only the other day, on a intercontinental link, it worked well enough to get me into a remote box and fix the configuration issue that was frustrating a client, not exactly lag free, but good enough to get the job done.

On a side note, I despise applications where you can ONLY configure the things with a GUI, makes setup nearly impossible to script.

Regards, Dan.

[bd139]

X11 is very efficient and fast if you use it as intended, which most people don't

There are a number of problems with Firefox however over X11. Firstly it repaints like a bitch due to incremental page loading. That results in masses of network traffic just loading a single browser frame. This works absolutely fine when you have a local graphics card but over the network it runs like ass. Then there's their handling of issues which is basically "remove the X11 extension that makes this fast" if there's a bug in Firefox. They did this with XRender in FF 47 to much booing hissing and fist shaking. Since then it has been total shit.

If you look at Dillo for example that actually performs very well over X11 because the developers thought about it up front. I can't remember the package but there is one that renders fractals over X11. It did real time 10fps over a shared 10base2 network between a SPARC 20 and an Ultra 10 back in the late 1990s.

Honestly Firefox is a mismanaged stinking turd of a product running over a 30 year old network protocol so YMMV.

[legacy]

This works absolutely fine when you have a local graphics card but over the network it runs like ass.

yup, exactly the synthoms I have seen on the network sniffer 

If you look at Dillo for example that actually performs very well over X11 because the developers thought about it up front.

Code: [Select]

*  www-client/dillo-v3.0.5
      Homepage:      [url]https://www.dillo.org[/url]
      Description:   Lean FLTK based web browser
      License:       GPL-3

thanks, I am compiling it just right now 

Honestly Firefox is a mismanaged stinking turd of a product running over a 30 year old network protocol so YMMV.

maybe good for a comics tale 

[hendorog]

Rather then solving a (perceived or real) performance issue, I needed in the past a solution for the session management (the aforementioned beloved SunRays sadly weren't an option anymore after the Oracle takeover and subsequent killing of that product line).  I had some luck with X2GO (*if* one managed to find *good* matching versions of Windows and  X2GO): https://wiki.x2go.org/doku.php

Reading up it looks like x2go is derived from the early open source releases of NX.

[bd139]

thanks, I am compiling it just right now 

Don’t expect Firefox grade features

[guenthert]

[..]
I can't remember the package but there is one that renders fractals over X11. It did real time 10fps over a shared 10base2 network between a SPARC 20 and an Ultra 10 back in the late 1990s.
[..]

That might have been xaos (although there were others before).  Still around (free software never dies):
--8<--
tho@bananas:~$ xaos -speedtest
Driver speed: 8.4 FPS (7.3828 MBPS)
Memcpy speed: 3438.8 FPS (3022.3828 MBPS)
Missaligned memcpy speed: 2232.4 FPS (1962.0703 MBPS)
Size 6 memcpy speed: 132.2 FPS (116.1914 MBPS)
Result:0 Formulaname:Mandelbrot Time:548122 Mloops per sec:36.49
Result:0 Formulaname:Mandelbrot Time:534510 Mloops per sec:37.42
New image caluclation took 0.0522708 seconds (19 fps)
Approximation loop speed: 280.6 FPS
-->8--
(client on a 'Banana Pi', server is VcXrv on Windows 7 on a fairly recent Intel i5, network is WiFi  )

[bd139]

That’s the one! Good to see it still around. I remember being blown away how much faster it was on my then super expensive PII-300 running FreeBSD compared to my SPARCstation 20 at work even though that had two Ross hypersparcs in it.

[legacy]

besides, pseudo-color x-terminals(1) are ALL broken with GTK,QT,...
They only work with Motif 

(1) Tektronix XP2xx/XP4xx, NCD 4xx, HP Envizex/Entria, IBM X-thin, ... all broken

[legacy]

besides, even with OpenMotif, there are smart applications, clever developers, and ...

In theory, when an X11 application needs to perform various drawing graphics, text, etc, it should only have to specify various options for controlling how the data will be drawn, i.e. what foreground and background colors to use, how line edges will be connected, what font to use when drawing some text, etc, etc, etc, in order to avoid the need to supply billions of parameters to each drawing function.

Now, there is a graphical context structure of type 'GC' (G=Graphical, C=context) to be used, but, of course, in name of freedom, X-windows also allows certain applications to avoid to use GC to set the various drawing options in this structure.

So, instead of passing a simple thin pointer to this structure to any drawing routines, these applications silly pass a NULL and doing so then they need to supply billions of parameters to each drawing function, that ... causes a catastrophic congestion in the net-layer.

It's not clear to me why someone needs to do so, since t would be rather handy when an application often needs to perform several drawing requests with the same options, but that is what I have observed: those stupid implementations haven't initialized the graphical context, haven't set the desired options, and they haven't passed the GC structure to all drawing functions 

WTF? I have already modified the code to use the GC, and the number of requests has dropped by the 60%. 

It's on my customer's own code, definitely not a good example to follow, but what makes me worried is the suspect someone else in the world has already followed such kind of bad examples.

[westfw]

You mean: "Why do applications designed to operate with a tightly integrated graphics co-processor that typically has "many" computational elements, massive amounts of dedicated memory, and dedicated high-bandwidth memory paths, work so poorly when constrained to operate across a network link using only the graphics primitives from the early 1990s?" ?Gosh; that's a tough question!

[legacy]

work so poorly when constrained to operate

pseudo-color x11 terminal (e.g. Tektronix, NCD, HP, and IBM) are broken because all the modern version of lib_pango are broken and all abandoned on pseudo-color algorithms, and this causes a catastrophic smash of the colors on the video, plus visual corruption, in short, you see garbage on the screen for every X11-app that uses { GTK2, QT, ... } and this stuff.

Motif-Apps work well since they directly access libX11 and they don't have strange interactions for colors.

Mozilla was the ancestor version of Fire-flop, it was designed for Motif and it works fine, viewing a pic of Marisha Ray shows good colors (considering the hw is pseudo-color), it's also fast and comfortable, but it's not an HTML5 browser, and can't access the modern internet because it can't decode modern web-pages. But it shows how good was the old school-technology around the 90s.

Oh, and about the hardware, well I happen to own all of the above-mentioned X11-terminals, and for example, my Tektronix's one is nothing more than a MIPS-R3000 @ 25Mhz with 32Mbyte of ram, running VxWorks v5.3, on a common video chip made by Texas Instruments.

• CPU:  IDT-79R3052E @ 25Mhz (MIPS R3000 embedded core, without MMU nor FPU)
• RAM: standard SIMM72s, fp-50ns
• Video: Texas Instruments 34020, TI 34020AGBL-40, RAMDAC Brooktree BT458LPJ135
• NIC: 1x Ethernet Port, SONIC DP83934 chip
• UART: 2x Serial Ports, Philips SCC2692 Dual UART chipset with RS232 adapter
• CON: PS/2 Keyboard and Mouse ports
• CRT: 1x Standard 15pin VGA port

It's quite like a mini workstation, loaded with a super fast kernel (VxWorks) with dedicated native-tasks (x11-server, xfont, xterm, xconio, xwm, etc, netscape, mozilla, xpicview, etc ...) to X11.

It also has a session-manager, and other stuff.

[madires]

Actually the big problem are websites with several 100MB of CSS, fonts, images, scripting and just a little bit of content. All that has to be fetched, processed, rendered and displayed. And don't forget that the remote machine retrieves the web page and sends the web browser's output to a X11 terminal creating even more traffic. Then add protocol inefficiencies and the masterpiece of a web browser called Firefox. BTW, a modern bloated web page isn't any faster on a 3GHz multi core PC with broadband internet access than an old school page from 20 years ago on a 200 MHz Pentium with a dial-up connection. Guess why

[legacy]

isn't any faster on a 3GHz multi core PC with broadband internet access than an old school page from 20 years ago on a 200 MHz Pentium with a dial-up connection

the problem I am trying to analyze is: X-windows is designed on XC, and XC means it needs to send the display-instructions (2d primitives) so the X-server on your local computer can re-create the screen on your local system.

there is a strong interaction between lib_{ pango, cairo, pixman, ...} (for { colors, fonts, etc }) and the framebuffer's engine has to decide which kind of primitive can be used at the pixel level, and this means a modern GPU can be probed for these primitives and then it can be addressed to do all the job in hardware (basically a GPU is a superset array of blitters, and coopers), rather than a poor virtual-framebuffer that can only be addressed by the Linux kernel to raster the screen in video-ram (that is kernel ram, in this case(1)), rather than probing a remote X11-terminal for the primitives, but this usually ends with - no, I don't have any acceleration, give me pixel-display-instructions, and this causes a congestion due to too many requests.


(1) I have recently used a similar trick to attach an LCD to the USB port by using the virtual framebuffer offered by Linux. Basically, X11 believes to have a true fb-devices and when it probes, and the virtual-device answers that it owns some capabilities, so X11 is happy. But the virtual-device is all implemented in software, inside a kernel module, and it uses the kernel some functions to handle 2d-primitives in kernel memory, that means when a line in the allocated video-memory gets modified (a pixel has changed) the MMU sets a dirty bit(2), and the Kernel triggers a packet to be sent to the USB-bulk engine, that shoot a packet to the USB-LCD to say "hey? a pixel has changed, update your screen with this instruction, change_pixel(x,y,color)).

Each pixel can virtually request a packet to update the LCD, and this of course sucks. Thus in the revision-B, I have modified the code with a queue of operations pending to be served, and if in the queue there are pixels that belong to a line, then their requests got dropped from the job-queue and replaced by a single request do_linx(x0,y0,x1,y1). Besides, the new algorithm works with a time-windows of 100msec, and with that deadline, when a group of pixels has changed it shoot the packet to the USB-LCD, otherwise just wait and keep putting notifications into the queue.

The speedup is interesting. Anyway, It's good for an x-term where you can play with "nano" and "emacs" on it by vt100 emulation, but it's still so annoyingly slow for everything else.

A better improvement might be the capability to move a block of video-ram by shooting just one packet, rather than a lot of packets describing each line in the block, and basically, this also seems to be *THE* problem with Fire-flop 


(2) the MMU handles 32Kbyte of ram per block, when a block gets the dirty-bit set it means one or more pixels inside the block have changed, then the MMU triggers the bit and the block is compared with the previous version, sort of dual buffering, to detect exactly what has changed.

[legacy]

... and the successor of X11 will probably be mr.W, Wait? W-who? give me a "W" for Wayland!!!