Linked by Thom Holwerda on Sat 28th Jun 2008 22:09 UTC, submitted by diegocg
X11, Window Managers "Maybe I'm just naive, but designing a graphics API such that all image data had to be sent over a socket to another process every time the image needed to be drawn seems like complete idiocy. Unfortunately, that is precisely what the X Window System forces a program to do, and exactly what Cairo does when drawing images in Linux - a full copy of the image data, send to another process, no less, every time it is drawn. One would think there would be some room for improvement. Unsurprisingly, others felt the same way about X, and decided to write an extension, Xlib Shm or XShm for short, that allows images to placed in a shared memory segment from which the X server reads which allows the program to avoid the memory copy. GTK already makes use of the XShm extension, and it seems like a good idea to see if Gecko couldn't do the same."
Thread beginning with comment 320545
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Overstated conclusion
by tyrione on Sun 29th Jun 2008 03:51 UTC in reply to "Overstated conclusion"
tyrione
Member since:
2005-11-21

1. I agree that using XShm when the client is local is good.

2. I'm surprised that Cairo did not already use it.

However, it looks to me like XShm reduced the total time by only about 20% and the author concluded that the original way was "idiocy", which seems a bit over the top, especially considering the extra flexibility of the socket approach.

Despite all the moaning about X I hear on this site, not one of the 40 or so users I have running complete desktops via remote X over 100mbit lan has ever once complained to me about their screen update speeds.


100BaseT is the baseline for no-one to complain. Move back to 10baseT or 10base2 and compare it's performance in a network environment next to OS X and it's WindowServer approach.

Reply Parent Score: 4

RE[2]: Overstated conclusion
by siride on Sun 29th Jun 2008 05:00 in reply to "RE: Overstated conclusion"
siride Member since:
2006-01-02

I've used such and I haven't found X to be slower really at all. In fact, because two machines are involved, it created a sort of dual core environment, where one CPU did X and the other (on the remote machine) ran all the programs.

Of course, GTK+ was a little laggy, but it's that way even with a local connection.

I've also done remote X across a campus network (actually, between two networks on the campus) and it was tolerable, with a little bit of lag. Part of the problem was the shitty X server running on a slow Windows machine on my end.

Reply Parent Score: 6

RE[2]: Overstated conclusion
by dmantione on Sun 29th Jun 2008 08:01 in reply to "RE: Overstated conclusion"
dmantione Member since:
2005-07-06


100BaseT is the baseline for no-one to complain. Move back to 10baseT or 10base2 and compare it's performance in a network environment next to OS X and it's WindowServer approach.


If the application is well written (properly uploads all its images to the X server and reuses them), X still rules over a 10 mbit network compared to RDP, because you have an Xserver with all extensions activated. RDP can only do 2D RGB screen updates (which it does this very well), but cannot do YUV, 2D rendering (Xrender) or 3D.

Watching a DVD with Xine on a remote Unix server, for example, works rather well because a PAL frame is just 720x288 pixels 50 times a second. YUV data is only 16 bits per pixel. Xvideo on the Xserver takes care of RGB conversion, deinterlacing and scaling.

Doing this with RDP works very badly, because if you watch full-screen at 1280x960 the RDP server needs to send 1280x960x32bit@50Hz, which is even doubtfull on a 100mbit network.

Further, note that X is not so much bandwidth but more latency limited. Therefore, over the internet is performs poorly, while RDP shines when running over the internet.

Reply Parent Score: 8

RE[3]: Overstated conclusion
by Tom K on Sun 29th Jun 2008 08:41 in reply to "RE[2]: Overstated conclusion"
Tom K Member since:
2005-07-06

It sounds like you're thinking of VNC. I'm pretty sure that RDP only sends the *instructions* and raw image data (if needed) to draw the window on the client side.

So no, watching a DVD wouldn't be a full-screen update @ refresh rate.

Reply Parent Score: 3

PlatformAgnostic Member since:
2006-01-02

Work is being done to alleviate at least one of the limitations you mentioned in RDP. The video problem is interesting too, and the general solution adopted by some folks (but not RDP afaik) is to send the compressed video data through a side channel and decompress it on the client side. This seems like the only workable design to me.

Reply Parent Score: 3

RE[2]: Overstated conclusion
by Soulbender on Sun 29th Jun 2008 12:07 in reply to "RE: Overstated conclusion"
Soulbender Member since:
2005-08-18

Move back to 10baseT or 10base2 and compare it's performance


True but we're in 2008 now, not 1990, and no one is using 10baset and 10base2 anymore.
If you do, well, get with the program.

Reply Parent Score: 5

RE[3]: Overstated conclusion
by sbergman27 on Sun 29th Jun 2008 17:19 in reply to "RE[2]: Overstated conclusion"
sbergman27 Member since:
2005-07-24

True but we're in 2008 now, not 1990,

Actually, I did not directly address this issue in my previous response to tyrione. X works about as well under 10baseT as 100baseT. People have a tendency to think in terms of bandwidth. X actually does quite well over limited bandwidth. It is latency which kills the standard (non-NX) X protocols. 10baseT has essentially the same latency as 100baseT. The most dramatic way to demonstrate standard X's sensitivity latency is to set up a ppp connection over an external modem. Start an application like Firefox and watch the lights. According to, I believe, Keith Packard some years ago (who had worked on LBX previously), approximately 90% of the round trips were actually unnecessary and an artifact of the then current implementation, and not inherent in the protocol itself. He was working on eliminating those unnecessary round trips. Not sure where we stand today.

However, it does not really matter, because for any sort of WAN connection we have NX.

Edited 2008-06-29 17:26 UTC

Reply Parent Score: 3

RE[2]: Overstated conclusion
by sbergman27 on Sun 29th Jun 2008 14:14 in reply to "RE: Overstated conclusion"
sbergman27 Member since:
2005-07-24

You are comparing apples to oranges. Even more of my users run from remote offices using NX (which is still really X). And believe me... NX blows RDP out of the water for both speed and quality over WAN connections. They are not even in the same class. Proxying RDP (or VNC) through an NX server helps some, but not that much. The OSX approach is nothing but VNC, which is noticeably poorer in quality and speed than even RDP.

X has Xshm which is optimum for local clients, straight X which is optimum for LAN environments, and NX which is optimum for WANs. No other windowing system can touch that combination for performance and flexibility.

Edit: I should mention that as amazing as FreeNX is... it has the rudest and most unhelpful support mailing list in all of Open Source, to the point that if I had another option that was even remotely as good I would migrate to it.

Edited 2008-06-29 14:17 UTC

Reply Parent Score: 7

RE[3]: Overstated conclusion
by tyrione on Mon 30th Jun 2008 10:36 in reply to "RE[2]: Overstated conclusion"
tyrione Member since:
2005-11-21

You are comparing apples to oranges. Even more of my users run from remote offices using NX (which is still really X). And believe me... NX blows RDP out of the water for both speed and quality over WAN connections. They are not even in the same class. Proxying RDP (or VNC) through an NX server helps some, but not that much. The OSX approach is nothing but VNC, which is noticeably poorer in quality and speed than even RDP.

X has Xshm which is optimum for local clients, straight X which is optimum for LAN environments, and NX which is optimum for WANs. No other windowing system can touch that combination for performance and flexibility.

Edit: I should mention that as amazing as FreeNX is... it has the rudest and most unhelpful support mailing list in all of Open Source, to the point that if I had another option that was even remotely as good I would migrate to it.


Let's not compare WindowServers of OS X to Xorg. Apple didn't design WindowServer around the notion of a VPN/RDP approach.

I will be interested to see how Apple reimplements NXHost and beyond for 10.6 and the Enteprise.

Reply Parent Score: 3