Re: CVS olicha: * Fixed transparent animated menu
Hi! Nice to hear that fvwm will have support for that fancy transparency feature. Just a few comments. On Sat, 5 Jan 2002, Dominik Vogt wrote: [SNIP] 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. Of course, ParentRelative gives you not the contents of the parent window, but only its BackgroundPixmap with a correct offset. So, if there's something more than just a wallpaper on a root window (e.g. Windoze-style icons/shortcuts), they aren't copied. Of course, unless they are drawn on the same pixmap that is a BackgroundPixmap. [SNIP] 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. You don't have to redraw the background yourself, all you have to do is call XClearArea(). The server will update the background itself and send you an ExposeEvent, upon receipt of which the app should only redraw all foreground elements. I.e., in no case should the app redraw the background -- if either the BackgroundPixmap or BackgroundPixel are specified, the server will do the dirty work itself. This feature significantly improves performance, especially if the server and the app are on different machines. The only exception is when BackgroundPixmap=None, but that means that app knows what it is doing. [SNIP] 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. There's an extension of double buffering: when the same pixmap is used as a BackgroundPixmap and as a shadow buffer. In that case one has to manually copy parts of that pixmap onto the screen only upon changes, and all the subsequent redraws are done by the server -- the app may completely ignore Expose events for such shadow-buffered windows. As to ParentRelative in general: I've tried to use it in Motif apps to make nice wallpapered dialog windows. This feature *is* useful, since you don't have to manually put/assign parent's background pixmap to all widgets (labels, checkboxes etc.). But a lot of work yet have to be done by the program, since the top/bottom shadows, focused widget rectangles etc. should be correctly generated taking the background into account. _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- 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]
Re: CVS olicha: * Fixed transparent animated menu
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]
CVS olicha: * Fixed transparent animated menu
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 ? -- 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]
Re: CVS olicha: * Fixed transparent animated menu
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? Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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]
Re: CVS olicha: * Fixed transparent animated menu
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. 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). 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. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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]
Re: CVS olicha: * Fixed transparent animated menu
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. 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. 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) 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? In any case, a pixmap copy of the root window may be better than the ParentRelative pixmap under certain situation. But what do you mean by double buffer. Olivier -- 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]
