On Wed, 2006-11-15 at 01:22 +0000, Ioannis Nousias wrote:
> You might have hear this before. I just came across it today.
>
> from http://blog.beryl-project.org/
>
> "I am running your svn and have noticed this non-tfp Beryl, what is
this?
>
> It is exactly what it sounds like, an early attempt (with some success I
> might add) to make Beryl run without the need for texture_from_pixmap.
> No more black window bug from nvidia, no more Xgl, no more AIGLX. Oh
> yeah? and its faster than Xgl/AIGLX (nvidia beta performance looks to be
> about the same). The code is all thanks to Onestone who is a true bling
> hero, and the idea itself originates from the Project Looking Glass
> people. Kudos to them and their great work, we hope to incorporate more
> of their experience to Beryl?s code base in the form of optimizations
> and improvements."
>
> it seems to be still in it's infancy though. Even if it's not as
> good/fast as the GLX extension, it's still nice to have an alternative
> path in case the extension is not available.
I'm assuming that they CopyTexSubImage pixmap content into textures.
This is nothing new. We knew that this works when writing the
GLX_EXT_tfp spec, of course. We actually agreed that CopyTexSubImage is
the appropriate way to handle the case where you have a window that is
larger than the maximum texture size. However, that very rarely happens
so there hasn't been a lot of motivation for adding this fall-back path
to compiz yet.
Using CopyTexSubImage might give similar performance to GLX_EXT_tfp
implementations right now as they are not very optimized yet. However,
CopyTexSubImage will always require a copy operation to get the pixmap
content into a texture and as both a texture and a pixmap need to exist,
the memory consumption is twice the amount that is really necessary.
CopyTexSubImage also requires you to do glXMakeCurrent each time you
need to update a texture, which can be expensive. GLX_EXT_tfp solves all
these issues.
-David