Re: Transparency Support ( was: issues for future version )

[Sasha_Vasko osca state mo us]

> On Thu, 30 Aug 2001, Sasha_Vasko osca state mo us wrote:
>
> > >
> > >    Why realtime shading/tinting for a static background image? For
> > > IceWM I added the possibility to announce another pixmap per
> > > ROOT_PIXMAP_ID than displayed on the desktop. Yes that's really waste
of
> > > memory. But this approach blasting fast, allows amazing effects (your
> >
> > Do you mean you create more pixmaps - one for each shade/tint ? AFAIK
> > - that's the exact cause of the fact that Eterm is such a memory hog.
>
>    I have exactly two images in 1.0.9: DesktopBackgroundImage and
> DesktopTransparencyImage.
>
>
>    - when both configuration strings are empty no background image is
>      loaded
>    - when only the first one is set the image specified is loaded and
>      the pixmap id generated is passed to XSetWindowBackgroundPixmap
>      and _XROOTPMAP_ID
>    - when both are specified and differ the first one specifies the
>      image announced per XSetWindowBackgroundPixmap and the second
>      one specifies the image announced per _XROOTPMAP_ID.
>
>
>    As said before: Quick, dirty and completely optional.

Well ok, its a viable approach too, but there is a distinct need among
users
for ability to have different shade/tint in different windows, in which
case
that would not work. Besides when having several desktops with different
backgrounds on them, you'd waste considerable amount of memory since,
you'll
have to maintain 2 pixmaps for each. Four 4 desktops on 1280x1024 that
would
make about 12MB.

> > > imagination is the limit) and people insisting on this eyecandy
normally
> > > should have more than enough memory.

Not quite so. I keep getting regular e-mails thanking for making aterm
produce transparency efficiently on rather limited machines.  Even I was
running it on 96 megs up untill this year. 12 MB would make aot of
difference
for me. Even now, having 256 MB, running two monitors, after opening up
several
Mozilla's, while debugging AfterStep with libefence I run out of memory
pretty fast. So memory is great concern when it comes to graphics.

> > >    Something that really bugs me is the reaction of some apps on the
> > > destruction of the ROOT_PIXMAP_ID (e.g. when you restart the window
> > > manager): Some apps simply crash if you are not careful enough (e.g.
> > > gnome-terminal). Other apps don't/hardly recover when your are
careful
> > > (XChat, Eterm). Being careful in my terms means removing of the
> > > ROOT_PIXMAP_ID as soon as it becomes invalid.
> >
> > Naturally. You have to update property first then wait for some time,
> > so that all the interested clients get PropertyNotify, and only then
can
> > you destroy the Pixmap. Otherwise clients may attempt to use invalid
> > pixmap when ConfigureNotify comes in front of PropertyNotify.
>
>    Hmm... Shouldn't it help simply to call XSync before destroying
> the pixmap?

Well, that would help abit, but it will not solve the problem completely.
You have to actually wait for PropertyNotify arriving to all clients, which
may take some time even after XSync, and if window is being moved/resized
at
the same time, which is often the case - you gonna get mixed results.

>
> Mathias

Sasha.