Re: Re:FW: XFree86 future

On Sun, 2003-03-23 at 04:35, Lukas Molzberger wrote:
> > Don't worry, we're not planning on getting rid of the client-server
> >model any time soon.  David Wexelblat is correct in the sense that 
> >the majority of people do not need it, but it's definitely the case 
> >that some people find it essential.  Not only that, I disagree with him.
> >I think direct rendered 2D has little to no benefit.
> >
> >
> >                        Mark.
> 
> 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 
> performance. Many people argued that the device drivers are to blame for the 
> bad 2D performance but I would think that it is a much harder problem to get 
> the 3D part of the graphics driver right than it is to get the 2D part right.
>I'm certain that network transparency together with the ancient X11 API's are 
> a large part of the problem of the XFree project. I've worked on several 
> projects where network transparency was involved and it allways made the 
> projects much more complex and made it almost impossible to get a satifactory 
> realtime performance.     


I've done a reasonable amount of looking at 2D application performance 
and I've never seen the network layers be a significant performance 
issue for a well-written app, especially for local rendering.
The network architecture of X is very well designed.

Why is 2D performance less than wonderful on X currently?

 - Applications still aren't take full advantage of RENDER for rendering
   operations that work better with RENDER.

 - Applications are getting closer and closer to the  point where all
   rendering is via RENDER, but RENDER isn't optimized,
   even ignoring acceleration. Fairly small amounts of work on
   the software layer could make RENDER many times faster than it
   is currently.

 - Flickery rendering ... e.g., tearing between the window border and
   contents when opaque resizing. A relatively simple extension to  
   support temporary redirection of portions of the window hierarchy
   would fix this.

3D is a very different case than 2D; two examples:

 - The amount of data being pushed around is much larger. 
   At the very worst, a 2D app needs to send a few times the
   screen real-estate worth of pixels at 20-30-40 frames.
   Most apps are much less demanding. 3D applications, especially
   games, need to send enormous quantities of textures and vertices
   to the graphics card.

 - Interaction between multiple applications is not typically
   a big deal. A 3D app renders into a fixed area of the screen
   or the whole screen and that's all. On the other hand,
   imagine a window manager resizing a alpha-blended dialog
   that overlaps another window. No matter who is pushing the
   bits to the graphics card, you are going to have IPC going on.

There are significant benefits to the X architecture:

 - Remote display. Yes, not everybody needs this, but it is frequently
   pretty darn useful. There is the argument to just use VNC, but
   if nothing else, VNC is certainly going to have a lot of trouble
   supporting application integration between apps from different
   computers with overlapping windows, DND, etc. (*)

 - Very strong isolation of clients from server implementation. 
   X clients from 10 or more years ago can remote display to X
   servers running on the newest versions of MacOS and Windows.
   There is a lot of ability to change the way the X server works
   and still maintain compatiblity.

 - More stability and security than direct FB access can ever provide.

Throwing these away just because of a lack of understanding of
the X architecture or an inability to get the needed improvements
into the X code base would be silly.

Regards,
                                                Owen

(*) I could certainly imagine a rootless VNC X server, with support
    for proxying client messages between apps, etc, and maybe that
    has been done, but at some point, the distinction between that
    and using X remotely becomes small.