Expose Events change ?
ajax at redhat.com
Mon Jan 30 11:21:35 PST 2012
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
But your response to them is always the same: paint the exposed area.
Most toolkits will get this level of detail right for you.
More information about the xorg