On Thu, 2009-01-22 at 15:24 -0500, Kristian Høgsberg wrote: > 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 ;)
The problem seems to be that the old indirect DRI texture from pixmap, kludged around for pixmaps which had a 24 bit depth. With DRI2, you're getting a RGBA texture, without the GL code "realising" that the texture's alpha channel should be 0xFF. I had attempted to hack round the problem in compiz, but it seemed that the DRI2 texture from pixmap ought to do similar things to the DRI one. I couldn't quite figure out why my compiz hack didn't work properly.. once I'd turned off the blending for the window texture, I got big black rectangles for shadows - even though I thought the decoration was drawn separately. When the GLXPixmap is created for binding the texture from, it is being associated with a FBConfig. That is selected based on the depth of the redirected window pixmap - so perhaps, as you say, the fbconfigs are advertising 8 bit alpha for every one. I guess the real question is this.. how should the texture from pixmap extension behave if the underlying pixmap has no (valid) alpha data? DRI1 would give you a texture with solid alpha channel. DRI2 is quite happy to give you a texture with alpha channel, but with undefined contents. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ------------------------------------------------------------------------------ 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
