[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