Xorg is sending a never ending expose event storm if xcompmgr
is running and another window is completely hiding an
E17 shelf that is set to be Below Windows.

In this screen shot:
http://www.fabiankeil.de/tmp/e17-transparency-completely-hidden-shelf-below-windows-1024x768.png
the top running Eterm is completely hiding the shelf
below it. Xorg continues to send expose events to E17
which cause high load because E17 redraws the shelf
all the time.

In this screen shot
http://www.fabiankeil.de/tmp/e17-transparency-partly-hidden-shelf-below-windows-1024x768.png
some of the shelf's pixels are in the foreground
and the expose event storm is gone.

As a work around one can set the shelf to be
"Below Everything".

I previously reported this as a E17 problem,
but Carsten Haitzler figured out that it was
an Xorg problem.

The mailing list archive seems to be down most of time,
therefore I'm just quoting his answer:

To: Fabian Keil <freebsd-listen@fabiankeil.de>
Cc: enlightenment-users@lists.sourceforge.net
Subject: Re: [e-users] E16 and E17 trasparency
Message-Id: <20060618095618.0f77a64b.raster@rasterman.com>

> i suspect this is some bug to do with xcomposite and x sending bogus expose
> events to the shelf thus the shelf redrawing - thus e redrawng it, its shape
> and having to recompute a dropshadow if you still have e's dropshadow enabled.
> (nb invisible shelves that are not "below everything" are largely useless).
> probably because e renders, sets shape mask, as a result x generates expose
> blindly even though there were no new exposures. i am suspecting this is a bug
> report for x.org :) but - put in some debugging (or use xev and the right
> window id to sniff events). in fact i just checked. suspicion confirmed. using
> xev i get a continual stream of never-ending expose events form x when the
> window shelf is covered:
> 
> Expose event, serial 13, synthetic NO, window 0x400159,
>     (6,0), width 338, height 40, count 0
> 
> Expose event, serial 13, synthetic NO, window 0x400159,
>     (6,0), width 338, height 40, count 0
> 
> Expose event, serial 13, synthetic NO, window 0x400159,
>     (6,0), width 338, height 40, count 0
> 
> Expose event, serial 13, synthetic NO, window 0x400159,
>     (6,0), width 338, height 40, count 0
> 
> Expose event, serial 13, synthetic NO, window 0x400159,
>     (6,0), width 338, height 40, count 0
> 
> Expose event, serial 13, synthetic NO, window 0x400159,
>     (6,0), width 338, height 40, count 0
> 
> 
> but when it is uncovered it works normally:
> 
> Expose event, serial 13, synthetic NO, window 0x400159,
>     (3,36), width 4, height 1, count 1
> 
> Expose event, serial 13, synthetic NO, window 0x400159,
>     (33,36), width 2, height 1, count 0
> 
> Expose event, serial 13, synthetic NO, window 0x400159,
>     (36,35), width 1, height 1, count 0
> 
> Expose event, serial 13, synthetic NO, window 0x400159,
>     (35,36), width 1, height 1, count 0
> 
> MotionNotify event, serial 13, synthetic NO, window 0x400159,
>     root 0x185, subw 0x0, time 3835547669, (7,14), root:(635,1174),
>     state 0x10, is_hint 0, same_screen YES
> 
> MotionNotify event, serial 13, synthetic NO, window 0x400159,
>     root 0x185, subw 0x0, time 3835547677, (6,14), root:(634,1174),
>     state 0x10, is_hint 0, same_screen YES
> 
> (for example).
> 
> so really - this isn't e's bug unfortunately - you should report this bug to
> x.org. what they need to know is:
> 
> using xcompmgr -n with xcomposite turned on and a shaped window, when the
> shaped window's shape mask is set while the window is fully obscured x
> continually sends expose events back to the shaped window even if the shape
> itself never changes (is the same shape all the time). this does not happen
> when the window is partially obscured or completely unobscured (the shape
> change generates more exposes that do not keep repeating if the shape
> itself does not change on a shape-set.