Re: Re: FW: XFree86 future

On Sun, Mar 23, 2003 at 09:32:09PM +0100, Lukas Molzberger wrote:
> Sure, you also have to do synchronization in a direct rendering model but it's 
> a whole lot easier if you don't have to take care of the network
> protocol.

Why would it be?

> If there is no network protocol then you don't need to keep backward
> compatibility of the network protocol.

Without a network protocol your interface is the ABI of your shared
library, and you have to keep backward compatibility of *that* - which
is at least as hard if not harder than keeping the network protocol.

> If the only possibility to keep backward compatibility is to add 
> new extensions to the core protocol then many problems will be solved in a 
> hackish way which leads to complexity and therefore also to other
> problems. 

Same is true of an ABI.

> The issue of backward compatibility also exists in the X11 API's but it's a far 
> smaller problem to break bw compatibility of an API then it is to break the compatibility 
> of a network protocol. Imagine the functionality that has been added from GTK 1.2 
> to GTK 2.0 would have been added just by extensions.   

2.0 is one big extension to 1.2. We keep 1.2 around installing in
parallel; see http://ometer.com/parallel.html

With a network protocol, we keep the old and new parts of the
protocol. It's the same thing, and equally complicated.  In both
cases, if everyone stops using the old thing someday, you could
theoretically delete it, but chances are you never get to delete it in
practice.

> Another problem of the X11 protocol is that events that an application wants to send 
> have to be compressed by the application to get a decent performance. 
> Correct me if I'm wrong, but as far as I have understood it, the only reason why this is 
> necessary is the network protocol.

I think I'd need more specifics to know what you mean here.

> > We also do have a reasonably OK-looking hack in metacity/GTK that uses
> > the SYNC extension to ensure that we do 1 frame repaint, 1 client
> > repaint, 1 frame repaint, 1 client repaint, alternating, instead of
> > what happens now where sometimes you redo the frame 30 times and repaint
> > the client only once. (The GTK patch for this hasn't been applied, so
> > there's no way to try this yourself yet.)
> That sounds nice! Will this work accross both desktops, Gnome and
> Kde?

It would if we standardized it, right now it's in the metacity namespace.
People on wm-spec-list didn't seem interested in standardizing it.

Havoc