Re: Borders and unmap with Composite

Keith Packard wrote:
> The Composite extension provides no names for the off-screen storage that 
> windows are placed in, right now I'm using the redirected window in 
> IncludeInferiors mode which mostly works.  The exception is that this does 
> not provide any way to get at the border contents.  I mostly don't care as 
> only insane applications use borders, and the Automatic update mode does 
> manage the borders correctly (as it can point at the pixmap directly).
> 
> However, it does produce quite visible artifacts on the screen when using 
> twm.  And, we all know how important twm is :-)
> 
> If this were the only problem, I'd be tempted to ignore it.
> 
> However, I've discovered a visual artifact that I think I can solve at the 
> same time.
> 
> When a redirected window is mapped, an off-screen pixmap is automatically
> created of the right size.  Conversely, when the window is unmapped, the 
> pixmap is automatically destroyed.  Creation doesn't really pose any 
> problems; when the compositing manager gets around to looking at the 
> mapped window the contents will be all ready (hmm, might be nice to find a 
> way to wait for the window to get painted, but I digress...).
> 
> Unmap, on the other hand, automatically destroys the pixmap.  If the 
> compositing manager is in the middle of constructing the screen image and 
> hasn't yet seen the UnmapNotify event, it will attempt to construct the 
> screen image including the now unmapped window.  The result is a visual 
> flash on the screen -- the translucent effects related to the window (aka 
> the shadow) is drawn, but the window contents are not.
> 
> I think I have an easy fix -- allow the compositing manager to name the 
> pixmap used for off-screen compositing and destroy it when it's done using 
> it.  This way, it will have a name for the object holding the border 
> contents so they can be drawn, and also the pixmap will hang around after 
> the window is unmapped so the old contents can be used in constructing the 
> screen image -- no more flash.
> 
> While integrating the compositing manager with the window manager would 
> eliminate flashing associated with managed windows, it will not eliminate 
> flashing from override redirect windows, while this naming scheme will.
> 
> This seem reasonable?  It should take almost 5 minutes to implement...

This reminds me of a GL issue.  Suppose you have two rendering 
contexts sharing a texture.  If the first context calls 
glDeleteTexture while the second context is still using the texture 
we've got a potential problem.  The usual solution is reference 
counting.  Binding (using) the texture increments the counter. 
Unbinding or deleting decrements the counter.  When the counter hits 
zero, we can really delete the texture.

-Brian