On Wed, Feb 01, 2006 at 04:45:29AM +0100, Marc Lehmann wrote: > Hi! > > The new argb visuals introduced by xorg have a serious drawback, namely, > they don't work correctly unless the toplevel window has an ARGB visual. > > With my limited knowledge, I'd say this is a design problem within Xorg, but > I seem to be alone with that notion. This means that each and every window > manager needs special support just to support ARGB in client windows. > > Here is a small patch I wrote that implements such support for fvwm: > > http://data.plan9.de/fvwm-2.5-argb-visual.patch
Small to medium sized patches can be sent directly to the mailing
list. That makes life for us much easier:
> Index: fvwm/add_window.c
> ===================================================================
> RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
> retrieving revision 1.374
> diff -u -p -r1.374 add_window.c
> --- fvwm/add_window.c 29 Jan 2006 09:57:18 -0000 1.374
> +++ fvwm/add_window.c 1 Feb 2006 15:17:11 -0000
> @@ -782,9 +782,31 @@ static void setup_frame_window(
> FvwmWindow *fw)
> {
> XSetWindowAttributes attributes;
> - int valuemask;
> + int valuemask = CWBackingStore | CWBackPixmap | CWEventMask |
> CWSaveUnder | CWCursor;
> + int depth;
> + Visual *visual;
> +
> + /*
> + * We assume that a truecolour visual of depth 32 is
> + * actually an ARGB visual (hard to detect otherwise)
> + * in this case, clone the window visual/cmap etc.
> + */
> + if (fw->attr_backup.visual->class == TrueColor
> + && fw->attr_backup.depth == 32)
> + {
> + depth = fw->attr_backup.depth;
> + visual = fw->attr_backup.visual;
> + attributes.colormap = fw->attr_backup.colormap;
> + attributes.background_pixel = -1;
> + attributes.border_pixel = -1;
> + valuemask |= CWColormap | CWBackPixel | CWBorderPixel;
> + }
> + else
> + {
> + depth = CopyFromParent;
> + visual = CopyFromParent;
> + }
>
> - valuemask = CWBackingStore | CWBackPixmap | CWEventMask | CWSaveUnder;
> attributes.backing_store = NotUseful;
> attributes.background_pixmap = None;
> attributes.cursor = Scr.FvwmCursors[CRS_DEFAULT];
> @@ -793,8 +815,8 @@ static void setup_frame_window(
> /* create the frame window, child of root, grandparent of client */
> FW_W_FRAME(fw) = XCreateWindow(
> dpy, Scr.Root, fw->frame_g.x, fw->frame_g.y,
> - fw->frame_g.width, fw->frame_g.height, 0, CopyFromParent,
> - InputOutput, CopyFromParent, valuemask | CWCursor, &attributes);
> + fw->frame_g.width, fw->frame_g.height, 0, depth,
> + InputOutput, visual, valuemask, &attributes);
> XSaveContext(dpy, FW_W(fw), FvwmContext, (caddr_t) fw);
> XSaveContext(dpy, FW_W_FRAME(fw), FvwmContext, (caddr_t) fw);
> What it does is "simply" check wether the client window has an ARGB visual
> and, if yes, creates the frame window in the same visual. Nothing else
> should be changed by this patch.
>
> The only relevant problem I see is the "detecting" part, as xlib gives no
> indication about alpha channels (would need to use XRender just for that),
> so it assumes that 32 bit TrueColour means there is an alpha channel (one
> could check bits_per_rgb or so to be <= 8, which means something weird is
> certainly going on, as 3*8 leave s8 bits unaccounted for).
>
> The other small uncleanlieness is the hardwired -1 for the pixel values,
> but that should hardly create any problems (all bits set boil down to
> opaque white - its not visible anyways, and is guarenteed to exist in such
> visuals).
But doesn't this change break normal (non-ARGS) 32 bit TrueColor
visuals?
> I was not sure what to do with the patch, I wrote it mainly for testing
> some things (not being a transparency geek myself), so I thought I'd send
> it to you to decide what to do with it :)
>
> Thanks for your attention, and thanks for maintaining fvwm2 :)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
