On Sat, Jan 05, 2002 at 12:50:44AM +0100, Olivier Chapuis wrote: > On Fri, Jan 04, 2002 at 06:27:43PM +0100, Dominik Vogt wrote: > > On Fri, Jan 04, 2002 at 05:52:36PM +0100, Olivier Chapuis wrote: > > > On Fri, Jan 04, 2002 at 02:23:55PM +0100, Dominik Vogt wrote: > > > > On Fri, Jan 04, 2002 at 07:08:45AM -0600, fvwm-workers wrote: > > > > > CVSROOT: /home/cvs/fvwm > > > > > Module name: fvwm > > > > > Changes by: olicha 02/01/04 07:08:45 > > > > > > > > > > Modified files: > > > > > . : ChangeLog > > > > > fvwm : menus.c menus.h move_resize.c move_resize.h > > > > > > > > > > Log message: > > > > > * Fixed transparent animated menu > > > > > * The result is not perfect with big menu, do I have to add a new > > > > > menu style AnimatedTransparentUpdate pix ? > > > > > > > > What would that style do? > > > > > > > > > > Hum, I do not know exactly. With big menus redrawing the menu during > > > the animation take some times (maybe some improvement is possible > > > in ParentalMenuRePaint). Even with a very few animation step this > > > gives an hashed animation. So, my idea was to skip some of the redraw, > > > but I am afraid that there is no good solution. Any suggestions is > > > welcome. > > > > I wouldn't put much effort into transparency. X has no proper > > implementation, so you'd have to write it yourself. > > Yes, but I think it will be great that colorsets work everywhere > as it is possible and Parental Relativity seems to give not so > bad results. The main problem (for me) is window background > update, but it is possible to fix this: xpmroot may send a > message to the root window, then fvwm2 can get this message > and ask the modules to update the transparent colorset.
Hm, seems to be worth a try. > Unfortunately, it does not seems that there is a standard > for this but some programs use the ESETROOT_PMAP_ID and the > _XROOTPMAP_ID atoms. Anyway, ParentRelative doe not really give transparency for top level windows. You don't see what is behind the window, only the contents of the root window there. > > The only > > thing I can think of is to double buffer the whole screen in a > > pixmap, calculate the animation in the pixmap and then copy the > > changed parts onto the screen (with the server grabbed). > > How can you dump the whole screen in a pixmap? If I use XCopyArea > then the areas of the root window where there is a window is black. > I try something like that: > > pix = XCreatePixmap(dpy, win, screen_w, screen_h, Pdepth); > XGrabServer(dpy); > XCopyArea(dpy, Root, pix, gc, 0, 0, screen_w, screen_h, 0, 0); > XUngrabServer(dpy) Good question. *** 10 minutes later *** If you set the subwindow_mode member of the used GC to IncludeInferiors, XCopyArea copies what's actually visible. I verified this with these lines: XSetSubwindowMode(dpy, Scr.TitleGC, IncludeInferiors); XCopyArea(dpy, Scr.Root, Scr.Root, Scr.TitleGC, 0, 0, 100, 100, 500, 0); XSetSubwindowMode(dpy, Scr.TitleGC, ClipByChildren); > > I guess > > some other window managers are already doing this. Enlightenment > > has a nice feature: You can move a window with partial > > transparency so you can see through the window while you move it. > > But that is quite slow and probably uses a lot of memory. > > > > I think that Enlightenment use the ESETROOT_PMAP_ID and the > _XROOTPMAP_ID atoms which give the id of a pixmap which is a > copy of the root window (KDE2 use these atoms too). Maybe we can > add EsetRoot as a pixmap argument for FvwmTheme? That's not what I meant. This is not real transparency because you can only see the root window through the transparent parts, not the windows that are in between. > In any case, a pixmap copy of the root window may be better > than the ParentRelative pixmap under certain situation. Both approchaes have one big problem: X doesn't do the updates itself. When you move a 'transparent' window, X moves whatever background it has. You have to redraw the background yourself. This looks very unpleasant. The right way to do transparency in X is to use the Shape extension. But then, applications have to be specifically written to use it. Also, remember that a copy of the screen can be very big:i 1600x1200 pixels with 32 bit planes = 7.5 MB. That's the reason why I did not go this way in the past. > But what do you mean by "double buffer". Keep a copy of the screen in a pixmap, draw into the pixmap, then copy the pixmap (or parts of it) onto the screen. Feel free to try anything to improve transparency of top level windows - though I believe any attempt to implement it properly in FvwmTHeme in a general way is doomed to fail. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
