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. I had a vague hope that the visual information of the GLXPixmap would be useful, but my test so far suggest that it isn't correct: I stuffed: fprintf (stderr, "intel_fb->... visual alpha bits is %i\n", intel_fb->Base.Visual.alphaBits); Into intel_tex_image.c's intelSetTexBuffer() function, but the printed result is always 8. (Even though I know compiz is redirecting various 24 bit depth windows). Should the information regarding the structure of the pixmap be stored against the GLXPixmap, or perhaps even the DRI drawable information? Is there any way to fix this without breaking ABIs? Best wishes, Peter Clifton. ------------------------------------------------------------------------------ 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
