On Thu, 2009-01-22 at 19:52 +0000, Peter Clifton wrote:
> Hi,
> 
> I've been looking into some texturing problems in compiz, seen when
> compiz attempts to make a 24 bit depth window transparent. Once it wants
> to make a window transparent, compiz's painting path switches on various
> texture operations which are affected by a corrupt alpha channel in the
> texture obtained using the texture from pixmap extension. (When backed
> by a 24 bit pixmap).
>
> I've gone round and round trying to figure out the right way this ought
> to be fixed, but I think we're missing some information.
> 
> The GLXPixmap created to texture from seems to be lacking information
> about the proper structure and depth of the underlying pixmap data.
> Since the texture can be bound from a direct GLX rendering context,
> there are two code-paths which call setTexBuffer, one in the GLX direct
> rendering path, and another in the GLX routines of the X server.
> 
> One could imagine using a hack like setTexOffset in the X server
> code-path, since we're more able to grab at the underlying data, but
> actually.. if setTexBuffer had the right information, we wouldn't need
> to do that.

Pixmaps don't associate a visual in the same way a Window does.
Typically you'll know what kind of contents it has from the context; if
it's a Pixmap backing a redirected Window, the Window's visual will tell
you, if you rendered something to the Pixmap yourself, you know what
visual to use.  So in the case of compiz, you'll have to look at the
visual for the redirected Window to know whether or not the Pixmap has
an alpha channel.  There may be a problem in that all the fbconfigs
provided by the DRI driver advertise an 8 bit alpha channel and thus you
can't pick an fbconfig when creating the GLXPixmap that correctly
advertises the lack of an alpha channel.  Can you just turn off
GL_BLEND?  Hmm, I guess I'm not sure what the problem is ;)

cheers,
Kristian



------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to