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]
