Re: [forum] Re: FW: XFree86 future

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Sun, Mar 23, 2003 at 01:30:42PM +0100, Lukas Molzberger wrote:
> > On Sun, Mar 23, 2003 at 10:35:19AM +0100, 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 
> > 
> > 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. 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.  

Which graphic card are you using, and remember, DRI does not move pixels
around, it only use the graphic engine to draw pixels on the framebuffer
from vertex and texture data, which often can be cached, whilepixel
moving performance, if accelerated, is mostly a factor of local memory
bandwith and the number of pixel pipe the chip has for moving them
around. An older chip, even accelerated, can be much slower than a newer
unaccelerated chip. I am sure that a 256 bit DDR memory bus as used by
the newer radeon, the parhelia or the wildcatVP would make unaccelerated
2D rendering much faster than even accelerated 2D on older chips.

> > That said, if 3D is really all that faster, i hear that OpenGL has also
> > a nice 2D API that could be used.
> Yes, but that would mean that Qt and Gtk would have to be ported to OpenGL 
> before it has any meaning to the enduser. That might solve the performance 
> problem, but it seems like a very hacky solution.   

That is their problem, they would have to be changed for using vector
graphics also anyway. Notice that there is an effort of porting Gtk+ to
Mac OS X natively. It is just gtk 1.2 right now, and i never tried it

> > > > 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 
> >  
> > Well, on local X, the network part is supposed to be almost transparent
> > and cost very little, so why remove it.
> 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. 

Mmm, i cannot say, i am running unaccelerated X right now, and it seems
pretty smooth, altough a bit jumpy. I guess if it was accelerated i
would not notice any difference, but then i am using a plain xterm, i
guess the problem mostly arise if you are using a translucent
gnome-terminal or something such.


Sven Luther

[X.Org]     [XFree86]     [XFree86 Discussion]     [XFree86 Newbie]     [IETF Annouce]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Samba]     [Linux Security]     [Linux RAID]     [Linux Resources]

  Powered by Linux