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 320552
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Overstated conclusion
by dmantione on Sun 29th Jun 2008 08:01 UTC 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

RE[4]: Overstated conclusion
by dmantione on Sun 29th Jun 2008 09:39 in reply to "RE[3]: Overstated conclusion"
dmantione 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.


Try it and watch the difference between Windows & Linux. Highly recommended.

The difference between VNC and RDP is that VNC captures the desktop and sends modified part, while RDP sits at the GDI level, it sends GDI drawing commands over the network. As the GDI has no "overlay" facilties, watching video on RDP falls back to sending RGB images over the network.

Reply Parent Score: 5

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