David Dawes is maybe the most active XFree86 developer and he is also the lead founder of the project. He works for Tungsten Graphics, which is the main company working on the XFree, DRI and Mesa codebases today. We are happy to host an interview with David, discussing the present and future of XFree86 project. Update: Still confused how a VSYNCed desktop look like? Read here.
Permalink for comment
To read all comments associated with this story, please click here.
I know you can use shared memory for data sharing in XFree but you still need the sockets or some other equally "selectable" IPC mechanism. The reason? Well most applications INCLUDING Gtk+ use a select()/poll() call to wait on the socket descriptor from the X server. SVR4 IPC mechanisms don't allow for asynchronous operation and will force anything but the most trivial client to become threaded. I am not knocking the fact they are using IPC but the fact HOW they are using it. Client/Server models regardless if they are statefull or stateless are inefficient due to communication overhead and client service order (which is unknown).
Display systems that use a widget toolkit at the server side has two major advantages.
- Look'n'feel. Every application will have the same look'n'feel regardless when or where they were developed.
- Fast redraw times of static content.
These are two both nice things but they won't save the server roundtrip times when I don't use static content or when some widget isn't provided by the display server. Look at your browser for instance, where would you put the network part of the browser? In the client. Where would you put the DOM tree part? In the client. Where would you put the display routines? In the client. What do you have left to put in the server side widget library? Nothing. The most commonly used application on Earth (except for maybe Emacs and MS Minesweeper =)) doesn't apply properly to that paradigm and I bet many other application won't either.
Ok first up. The IPC.
I know you can use shared memory for data sharing in XFree but you still need the sockets or some other equally "selectable" IPC mechanism. The reason? Well most applications INCLUDING Gtk+ use a select()/poll() call to wait on the socket descriptor from the X server. SVR4 IPC mechanisms don't allow for asynchronous operation and will force anything but the most trivial client to become threaded. I am not knocking the fact they are using IPC but the fact HOW they are using it. Client/Server models regardless if they are statefull or stateless are inefficient due to communication overhead and client service order (which is unknown).
Display systems that use a widget toolkit at the server side has two major advantages.
- Look'n'feel. Every application will have the same look'n'feel regardless when or where they were developed.
- Fast redraw times of static content.
These are two both nice things but they won't save the server roundtrip times when I don't use static content or when some widget isn't provided by the display server. Look at your browser for instance, where would you put the network part of the browser? In the client. Where would you put the DOM tree part? In the client. Where would you put the display routines? In the client. What do you have left to put in the server side widget library? Nothing. The most commonly used application on Earth (except for maybe Emacs and MS Minesweeper =)) doesn't apply properly to that paradigm and I bet many other application won't either.