Re: Re: FW: XFree86 future

Am Sonntag, 23. März 2003 19:49 schrieb Havoc Pennington:
> On Sun, Mar 23, 2003 at 01:30:42PM +0100, Lukas Molzberger wrote:
> > > > If direct rendered 2D would bring little to no benefit why then is
> > > > the performance of direct rendered 3D under XFree so much better than
> > > > the 2D
> > >
> > > How can you compare them ?
> >
> > I admit that this is mainly a subjective thing, but in 3D I can load
> > really complex objects and I can move them around and it feels smooth and
> > fluent. The 3D won't let me see any broken or incompletly drawing states.
> > But that's the case on the X11 desktop. Sometimes I can watch the system
> > redrawing a window. The X11 desktop just doesn't feel good.
>
> This isn't primarily about speed, it's about
> flicker/tearing/lack-of-animation, as already discussed.
That is true, but it's also a speed problem.
>
> What makes it harder in the X11 case vs. the 3D/direct-rendering case
> is not network protocol vs. direct-rendering, but the fact that
> multiple applications are involved that need to be synchronized.  If
> you are doing direct rendering, you still need some way to do that.
>
> This is a completely solveable problem.
>
> > That's not only a XFree problem but a general problem of X11. I've
> > used several X11 implementations (in Irix, AIX, Solaris) and it's
> > always the same.
>
> As far as I know, all these X11 implementations are more or less from
> the same codebase, so unsurprising. ;-) But even so, the protocol
> needs extending to allow apps to coordinate double buffering and such,
> you can't fix this totally in the server implementation.
>
> > My point is that the client-server model does not only have a performance
> > penalty but more importantly that it also makes X11 as a whole
> > unnecessarily complex. It makes it difficult if not impossible to fix
> > certain issues in XFree and the complexity also scares possible new
> > developers away. Take for example the problem of resizing opque windows.
> > It looks extremly slow and broken even on fast hardware. That's not
> > really a performance problem but a synchronization problem between the
> > WM, the XServer and the application. I've asked about this issue before
> > and everybody seem to agree that it is pretty much impossible to solve
> > this issue with the current X11 protocol.
>
> But direct rendering doesn't solve that either, at all. What solves it
> is an extension that lets us redirect frame and client drawing to
> backing store, then pop them both off at the same time when the unit
> is ready, or something along those lines.
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. If there 
is no network protocol then you don't need to keep backward compatibility of 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. 
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.   

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.     

>
> 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?
>
> Once you apply this patch you can see some performance issues still,
> but the profiler demonstrates that those are caused by image scaling
> and text layout, not rendering, in metacity's case.
>
> There's also some suckage from SHAPE when using windows with rounded
> corners, but SHAPE sucks in lots of ways and if we get real alpha
> channel we can stop using it.
>
> Havoc

Cheers
Lukas