Expose Events change ?

[Adam Jackson]

On 1/30/12 11:37 AM, Andrew McLean wrote:

> Thanks, but I'd still like to learn more about this change. Is it
> covered in any Release Note, for example ?

Not directly.  It's sort of fundamental to the larger feature that is 
the Composite extension.

> E.g. Indeed I don't currently receive any, but under what circumstances
> might I get them, and need to handle them ?

When in doubt, read the protocol spec.

The core protocol definition specifies the conditions under which Expose 
events are generated:

"This event is reported to clients selecting Exposure on the window. It 
is generated when no valid contents are available for regions of a 
window, and either the regions are visible, the regions are viewable and 
the server is (perhaps newly) maintaining backing store on the window, 
or the window is not viewable but the server is (perhaps newly) honoring 
window’s backing-store attribute of Always or WhenMapped. The regions 
are decomposed into an arbitrary set of rectangles, and an Expose event 
is generated for each rectangle."

In other words: something bad happened to your window, and you, dear 
program, must repair it.  The Composite extension spec amends this by 
defining window redirection states in which the X server promises that, 
in the language of the core protocol, "valid contents are available".

So that's pretty much just a long version of what I said in the first 
place.  If you have a compositor running (using the Composite extension 
to redirect window storage), then you usually won't get Expose events, 
because there are fewer times when the server will lose your window's 
pixel content.

But your response to them is always the same: paint the exposed area.

Most toolkits will get this level of detail right for you.

- ajax