[compiz] Re: [PATCH] Transparent cube

Vasek Potocek vasek.potocek at post.cz
Sun Apr 29 06:56:58 PDT 2007


Vasek Potocek napsal(a):
> Dennis Kasprzyk napsal:
>> Am Samstag, 28. April 2007 15:35 schrieb Vasek Potocek:
>>> Hello,
>>>
>>> is there any way of utilizing OpenGL's depth test instead of the paint
>>> order? If I understand it well, the aim here is to get it looking _like_
>>> with depth test. I understand that shifting windows by an 
>>> "infinitesimal"
>>> offset in the z direction would lead to various problems, but isn't is
>>> possible to persuade OpenGL somehow to use different coordinate for the
>>> depth test than for the perspective projection? (It would require a 
>>> little
>>> bit more math than I outlined here, but should be possible.)
>>>
>>> V.
>> For transparency effects you can't use a depth test, you have to paint 
>> the whole screen from back to front.
>>
>> Dennis
> 
> I'm sorry, I really forgot about the problem with transparency x depth 
> test. However, I still think this is soluble: what about using the 
> cubeCheckFTB function for deciding which glBlendFunc to use? Normally 
> we'd need to multiply the color drawn both by SRC_ALPHA and 
> ONE_MINUS_DST_ALPHA, which is not possible well enough, but thanks to 
> compiz' alpha-premultiply demand (fix me if it's not so), we could just 
> choose glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA); (as it is done now) 
> when drawing in front of all and glBlendFunc(GL_ONE_MINUS_DST_ALPHA, 
> GL_ONE); if drawing behind all. No other situation should arise in cube 
> + 3D with BTF (and no other situation would be soluble at all even the 
> original way, however).

Sorry, this was inexact, forget it, please. Of course, the current code draws windows in a 1-2-3-6-5-4 order or so. What 
is insoluble in both are more complex 3D effects which could cause windows for example intersect.

> I hacked together a little demo showing this, see the attachment and 
> comments in it.
> 
> One problem I can see is this needs the support for alpha bitplanes, 
> which is not so automatic, could we rely on it in Linux implementations?
> 
> V.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> compiz mailing list
> compiz at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/compiz


More information about the compiz mailing list