"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."
To read all comments associated with this story, please click here.
Member since:2005-11-21
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.
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.
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.
Member since:2005-08-18
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
Member since:
2005-07-24
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.
Edited 2008-06-29 00:08 UTC