[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg
Subject:    Re: Xgl/Xegl future?
From:       Michel =?ISO-8859-1?Q?D=E4nzer?= <michel () daenzer ! net>
Date:       2005-08-22 5:01:37
Message-ID: 1124686898.4488.118.camel () localhost
[Download RAW message or body]

On Sun, 2005-08-21 at 21:08 -0400, Owen Taylor wrote:
> On Sat, 2005-08-20 at 19:46 -0400, Michel Dänzer wrote:
> > On Fri, 2005-08-19 at 11:55 +0200, Christian Parpart wrote:
> > > 
> > > Will it be possible to do such amazing things w/o hardware-OpenGL-based 
> > > X server?
> > 
> > Yes. The major toolkits seem to be moving to GL backends, 
> 
> I can't speak for other major toolkits, but there is no current plan
> to do this for GTK+:
> 
>  http://mail.gnome.org/archives/gtk-devel-list/2005-June/msg00166.html

Thanks for clearing this up.


> > and there are proofs of concept of GL based compositing managers.
> 
> Well, the most impressive GL-based compositing manager demos have been
> the ones that Dave Reveman has been running on top of Xgl... 

I know, but I'm not sure that Xgl is actually a crucial part of it:

> In order to do a good job with a GL-based compositing manager you need:
> 
>  - Redirection of OpenGL and Xvideo clients

This is true whether the compositing manager is GL based or not.

>  - The ability to texture with the contents of redirected windows
>  - Decent video memory management that can handle large amounts of
>    textures. 
>  - Accelerated indirect rendering and/or good cooperation between
>    multiple clients talking to the hardware.

I fail to see how Xgl would inherently make a difference for any of
these. They're properties of the GL(X) implementation.


I agree with the other advantages of a GL based X server you cite
though.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

[prev in list] [next in list] [prev in thread] [next in thread]