Hi Mutlu,

Go ahead modifying compiz/libdecoration/decoration.c, I'd like to know
about your results/experiments. As I said before, I successfully got
the opaque-only title bars and opaque window decoration displayed but
anything non-opaque won't work.

What I didn't get/understand at that time was the fact that compiz
doing all the blending, effects and windows animation to a 16bit
physical screen (and seems like the transparency was working) and at
the same time, the window decorator failing to create 32bit offscreen
pixmaps, and thus windows get displayed without any title bars or
surrounding decoration, which is somehow contradictory.

Let me know about your changes.

Regards,
Ilyes Gouta.

On Tue, Jan 6, 2009 at 11:33 AM, Mutlu T. <[email protected]> wrote:
> Hi there,
>
> Thanks a lot for your prompt response. Yes Im trying to run compiz @16bit
> depth since my old Mobility Radeon (aka M6 LY) only has 16MB of memory to
> drive 1400x1050 panel of laptop. I wonder what was Sony thinking when they
> were building this particular machine. Anyhow after reading your post I
> decided to hardcode 16bit (or 24) values compiz/libdecoration/decoration.c
> but now that you say its messy I'll find a way to run beryl again on that
> machine. Or go nuts and give xmonad / wmii a go :) Give them a try I say, if
> you're keen with txt based managers.
>
> Thank you very much again, you have been most helpful and informative. I can
> let you know how things go, if you wont consider 'em spam :)
>
> Best regards,
> Mutlu Tunç
>
>
>
>
>
> On Tue, 06 Jan 2009 11:44:04 +0200, Ilyes Gouta <[email protected]>
> wrote:
>
>> Hi Mutlu,
>>
>> No not really, but I remember that there was an issue with DRI/intel
>> advertising a wrong list of pixelformats modes. Since Compiz is
>> creating the decoration pixmaps in 32bit and the physical pixelformat
>> I set was 16bit and DRI is reporting 16bit-only pixmap modes, the
>> subsequent creation operation fails. At that time I didn't understand
>> why DRI/intel driver is enforcing such a behavior, that is 32bit
>> offscreen pixmaps should be only created when the physical (screen)
>> format is set to 24 or 32 bit. After all, we're blending 32bit
>> *offscreen* pictures to compose the final desktop pixmap/texture which
>> can be, at the end, blitted to the 16bit physical screen and have the
>> pixels converted at that stage. Nowadays h/w blitters are able to blit
>> across different source and destination surfaces using different
>> pixelformats. I have never had an answer to my request at that time.
>>
>> I remember I had a limited success changing all the XCreatePixmap in
>> compiz/libdecoration/decoration.c to create the offscreen textures
>> using the screen's pixel depth mode and I got window decoration which
>> is opaque displayed correctly. However, most of the window decorations
>> (such as in emerald) require the alpha component of the pixel to
>> implement the various fancy effects such as transparent/rounded and
>> "composited" title bars and thus they *really* require the offscreen
>> pixmap to be created in 32bit mode. I remember I also had some
>> rendering glitches such as contours being left onscreen when resizing
>> a given window. It was really messy. I just abandoned.
>>
>> All in all, Warn: No GLXFBConfig for depth 32 means that your screen's
>> depth is set to something less than 24bit and the window decorator in
>> compiz/emerald/whatever is failing to create the offscreen pixmap in
>> that mode. Change the DefaultDepth in your /etc/X11/xorg.conf to 24 or
>> 32 or wait for a better DRI driver.
>>
>> I hope it helps :)
>>
>> Regards,
>> Ilyes Gouta.
>>
>> On Tue, Jan 6, 2009 at 12:13 AM, Mutlu T. <[email protected]> wrote:
>>>
>>> Hello Ilyes,
>>>
>>> I came acros your post @
>>> http://thread.gmane.org/gmane.comp.video.opengl.compiz-fusion.devel/365
>>>
>>> Sorry to bother you but I was wondering if you got any lucky with that,
>>> since I'm having the same problem with 32bit enforced decorations.
>>>
>>>
>>> Thanks for reading..
>>>
>>> Best regards,
>>> Mutlu Tunç
>>>
>
>
>
> --
> --
> MT
>
_______________________________________________
Dev mailing list
[email protected]
http://lists.compiz-fusion.org/mailman/listinfo/dev

Reply via email to