Subject: CVS olicha: * Fixed transparent animated menu

From: FVWM CVS <[email-masked]>
Date: Fri, 04 Jan 2002 07:08:45 -0600

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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 4 Jan 2002 14:23:55 +0100

> menu style AnimatedTransparentUpdate pix ?

What would that style do?

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
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-masked].
To report problems, send mail to [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 4 Jan 2002 17:52:36 +0100

> 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.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 4 Jan 2002 18:27:43 +0100

> but I am afraid that there is no good solution. Any suggestions is

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 ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 5 Jan 2002 00:50:44 +0100

On Fri, Jan 04, 2002 at 06:27:43PM +0100, Dominik Vogt wrote:
> 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
> 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

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

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 5 Jan 2002 21:05:21 +0100

> and ask the modules to update the transparent colorset.

Hm, seems to be worth a try.

> for this but some programs use the ESETROOT_PMAP_ID and the

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.  

>     XCopyArea(dpy, Root, pix, gc, 0, 0, screen_w, screen_h, 0, 0);

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);

> 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.

> 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-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Mon, 7 Jan 2002 14:18:51 +0600

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]
> 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]
> 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] 
> 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