[compiz] compiz 0.3.6 in fedora rawhide

[David Reveman]

On Wed, 2007-01-17 at 11:42 -0500, Kristian Høgsberg wrote:
> Hi,
> 
> I've just updated compiz in fedora rawhide and wanted to post a quick
> overview of the patches we still carry.  Patch details are available
> here:
> 
>   http://cvs.fedora.redhat.com/viewcvs/rpms/compiz/devel
> 
> terminate-move.patch
> restart.patch
> 
>   These are already upstream, but not yet in a released version.
> 
> aiglx-defaults.patch
> tfp-server-extension.patch
> 
>   These two paper over a problem in libGL by defaulting to indirect
> rendering and looking for tfp in the server extensions string.  The
> upstream compiz approach of trying direct rendering first and then
> falling back to indirect if direct doesn't support tfp should work.
> However, libGL only merges tfp into the glx extensions string if you
> set LIBGL_ALWAYS_INDIRECT, not if you request an indirect context.  So
> this is a problem we need to fix in libGL, but for now I'm keeping
> these patches in the compiz RPM.
> 
> fedora-logo.patch
> 
>   Branding patch, not upstreamable.
> 
> composite-cube-logo.patch
> 
>   I wrote this patch to allow the fedora logo (which is mostly
> translucent) to blend correctly on top of the cube.  I forget the
> details, but without it the blue background (that the branding patch
> sets) of the cube turns all black.  One of these days I'll look into
> it and try to come up with something upstreamable.

You need an alternative code path for when GL_EXT_texture_env_combine
isn't present. Just drawing the background color and then blending the
logo image on top of it would work but be a bit less efficient. Not sure
that it would be so much less efficient that it's worth keeping the
GL_EXT_texture_env_combine code path though.

> 
> So we're in pretty good shape here, looking forward to trying out the
> new blur plugin once we get marshalling for GL_ARB_fragment_program.

Blur plugin needs some more performance work but it should be ready
soon. However, you'll need a driver that accelerate glCopyTexSubImage2D
or it's going to be horribly slow. I don't know what the state of
glCopyTexSubImage2D acceleration is in current Mesa drivers but I know
that none of them used to accelerate it. I think the new memory manager
is required to be able to accelerate glCopyTexSubImage2D and similar
functions.

-David