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]
