Support transparent background colors on X11

[BwackNinja]

Also addresses issue #17

[meh]

This ends up breaking the window manager as it is, I get the same problem with termite.

What's the screen.root_depth() when transparencies are allowed? Is it 24 or 32?

[BwackNinja]

screen.root_depth() should always be 24. That's the depth of the root window, which doesn't have alpha.

I don't have any issues, with or without compositing. What window manager are you using?

[meh]

I'm using Fluxbox, from a cursory search when the depth of the window is different from the depth of the parent it's the window's job to deal with decorations and such.

What's happening is the window starts at 0,0 and has no decorations, it's like the WM is going "yeah whatever, I don't want to handle this window".

There must be some workaround, are you 100% sure the root depth is 24 bits even on compositors?

[BwackNinja]

Is there anything special about your Fluxbox configuration then? I tried in Fluxbox myself, both alone and with compton, and didn't see any issues.

I'm also 100% sure that the root depth is 24 in all cases (unless you're running X with 16-bit or 30-bit colors). I double checked by printing out the value.

Also, you get an rgba visual whether or not compositing is enabled. It's simply whether the screen supports rgba visuals, so if you aren't running a compositor and later start one, the window will have a transparent background.

[BwackNinja]

A quick google search says that you're probably encountering this: https://sourceforge.net/p/fluxbox/bugs/1102/

And just need to update your Fluxbox.

[meh]

Yep, it was Fluxbox being broken.

Now I have another doubt, is there a reason you removed the context push/pop? It avoids artifacts when rendering.

[BwackNinja]

I removed the context push/pop because the paint with the alpha channel draws over the previous content rather than replacing it. That's why o.set_operator(cairo::Operator::Source) is used - to replace existing content rather than draw over it. If that was used on the paint after the pop, then only the changes would appear, and the rest would be blank.

An alternative would be to draw on a secondary surface and paint that to the window, though the size of that surface would need to be kept in sync with the size of the window.

[meh]

Yeah, my plan was to have 3 surfaces:

1) the background surface, can be a custom background, a background taken from the root window, or just a transparency 2) the ReGIS surface 3) the actual terminal view

And then draw one after the other to the terminal view surface, I think I'll gut out the transparency stuff for now and keep the X11 stuff.

[meh]

Merged some of the stuff, thanks a bunch.