On Feb 9, 2008 11:39 PM, Dominik Vogt <[EMAIL PROTECTED]> wrote: > On Sat, Feb 09, 2008 at 11:01:15PM +0000, seventh guardian wrote: > > This is about support for argb visuals in fvwm windows (decors, menus, > > modules, etc).
To clarify myself, I mean selective transparency, each pixel having its own alpha value. That is, opaque text on transparent/tinted background, transparency gradients, using a pixmap with transparent/translucent parts, etc, etc. > > Surprisingly (or not), one can already specify that (s)he wants an > > ARGB visual for fvwm windows. First you have to run xdpyinfo to copy > > the id of the appropriate visual (tipically the last one). Then it's a > > matter of running "fvwm -I <vis-id>". > > > > If you're running a compositor (like xcompmgr), menus/modules with > > black backgrounds will appear with real full transparency!! (for > > window decors, it needs a slight change in the code). > > The problem is, there's currently no way of controlling this "power", > > so it ends up being useless as is. > > > > The first problem we have is that the user needs to manually specify > > the visual id, which changes with the xorg setup. Most users would > > expect some form of automatic configuration, so here are the > > alternatives: > > 1) Leave it as is (not user friendly nor portable, bad idea IMHO) > > 2) Provide a command line switch for argb, like "fvwm --argb" > > 3) Detect if the composite extension is present, and activate the argb > > visuals if it is. > > 4) Provide a config file option for argb visuals. > > I don't understand what this means practically. We want to select the visual to be used by the fvwm windows. This may mean monochrome, 8 bits color, 16 bits color, 24 bits color, 32 bits color with alpha channel (argb). Current code in fvwm.c, main() selects the visual related properties used by fvwm windows (namely the values of Pdepth, Pvisual and Pcmap). It tries to detect the appropriate visual, but the user can force a specific visual through command line. Unlike the rest of the code which uses those P* properties, strangely the window frames use CopyFromParent. This means that the user selected visual is ignored for the window frames.. We need to add some user friendly way of more or less automatically selecting the argb visual provided by the composite extension. > > Second, the argb visuals expect an alpha value of 0xff for fully > > opaque, and 0x00 for fully transparent. Most of the current code only > > "paints" the color values, so the alpha value ends up with 0x00, > > meaning full transparency. The notable exception to this problem is > > the font rendering, which prints as expected (fully opaque). This > > problem is a lot more complex, so I'll try to subdivide it. > > > > First, the rendering code needs to be revised to correctly accommodate > > another color channel. Our options: > > 1) Move away from "core X" and use XRender (IMHO the smarter change, > > as the it deals with these things "transparently". Some operations are > > server side and hw accelerated). > > 2) Change the current code to support another color channel, and deal > > with the nuances ourselves (easier on short term, but probably harder > > to maintain). > > I don't think we'll ever be able to implement (2) properly. Even > if we do we need to always remember the fourth colour channel in > the future. Even if it's doable it would result in unmaintainable > code. > > > Second, the colorset parsing needs to be revised. The severity of the > > revision is dependent on how we solve the previous problem. We need a > > way of storing the four color components. > > For fake transparency, we have "RootTransparent", "Transparent", and > > several "Tint" and "Alpha" options. When it comes to real > > transparency, it is a matter of using a four byte color code. I'll > > not provide a list of options for this one, because I don't know how > > to solve it.. It should be a compromise between compatibility versus > > simplicity... > > > > > > Finally, the modules need to be updated accordingly. It should be > > fairly easy to do once the other problems are solved. > > > Real transparency is a feature that a lot of users would like, yet it > > should bring no harm for the rest. It doesn't require a high end gfx > > card nowadays, since most modern cards support some form of 2D > > acceleration. > > > > Please give me some feedback on this, as I don't want to decide this > > on my own. > > I don't think general transparency (for any window) sould be added > to fvwm directly. I hope I clarified myself above, this is about selective transparency, and can only be used if fvwm paints the appropriate parts of the window with the appropriate argb color values. > The transparency stuff we have now is limited > to fvwm internal colour sets and modules, and honouring the > ParentRelative attribute. If adding argb visuals is much more > complex that this, I'd prefer to not implement it. It is a bit complex, but it is powerful. I'd like to have this feature, and a lot of users would drool about this.. > Transparency > could easily be handled by a third party tool (no idea if such a > tool exists) with support from the X server. All fvwm would have > to tell the tool is the window id and the alpha value. This is another form of transparency, and is already implemented by using xcompmgr as a compositer and transset as a tool to manipulate a custom window property for transparency. The type of transparency I'm talking about requires fvwm to paint 4 components colors instead of three, so it's not doable by an external program. I can submit some screenshots of what I've been hacking around with. Like they say, "1 picture is more valuable than 1000 words". :) Cheers, Renato
