Linked by Guillaume Maillard on Thu 10th Oct 2002 05:44 UTC
Being a BeOS user (a purely desktop system) and because I code under Linux, I see XFree86 (v4.1 on my machine) as a user and as a developper. And this is where the problem lies. My Gnome or KDE desktops are slow in comparison with other operating systems, but XFree86, the 'engine' behind these desktops, proves me that it's not. Let's look at what I have in front of me: a dual Pentium III at 933Mhz with 512MB of memory, a Radeon 32 AIW, a modified Mandrake 8.0 powered by kernel 2.4.18.
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Guillaume touches upon the symptoms of my biggest problem with X: the drawing code being part of the server, and consequently its poor use of shared memory. The symptoms appear in the way redraw events are handled:
In practice: let's start with an example: a screen with 10 windows.
1. I click on my preferred window and move it
2. the first 'step' of the move will:
- ask the Xserver to move the window
- 5 windows are partly covered, so 5 windows receive an ExposeEvent these 5 windows redraws the needed part. A 'standard' part of a nice UI need to send more than 100 drawing requests (line, rect, font...) to the Xserver. If my GnomeCalc is right, it's about 500 requests at every 'step', if I want to be have the more smooth desktop on earth on my 100Hz screen, 500000 requests must be swallowed per second.... good luck, it's not going to happen! Remember, it was 'just' to move a window and it already consume 100% of my CPU.
The server can ask the client at any time to redraw any portion of any of its windows. Not only does this make the clients unnecessarily complicated, but it leads to visible performace problems.
Quartz handles this by either: using a shared raster buffer which the clients can draw to directly, or by building a PDF document in memory that the server can re-render at any time without consulting the client. Because of this there is no display corruption when an application stops responding or is slow to respond.
X further suffers from having to multiplex what is sometimes very heavy socket traffic. In some cases this is enough to grind the X server to a halt as a particular client passes a barrage of drawing commands.
In a properly designed window server, IPC should only be used for synchronization and event processing, and all drawing should take place through the use of shared memory buffers. Clients should only have to redraw the entire buffer in the event that the window is resized.
Note that Win32 uses a similar architecture to X. Redraw lag is most visible in Windows XP when using shaped windows (as XP does per default with the Luna theme) See:
http://fails.org/xp
(taken on a 2GHz Pentium 4 system with the lastest stable Nvidia drivers, GeForce4 MX, and on a Pentium III system with a Rage 128)
People attribute this display corruption to "programming errors" in Putty and Internet Explorer. However, I attribute these problems to fundamental flaws in Windows itself. It shouldn't be possible for such display corruption to occur during redraw events through "programming errors". I think these screen shots make clear that having clients handle redraw events just isn't a very good way of doing things.
Quartz has shown a better way of designing window servers, and after using it, any other window server seems outmoded and clunky.