Function with_surface_tree_upward

pub fn with_surface_tree_upward<F1, F2, F3, T>(
    surface: &WlSurface,
    initial: T,
    filter: F1,
    processor: F2,
    post_filter: F3,
)
where
    F1: FnMut(&WlSurface, &SurfaceData, &T) -> TraversalAction<T>,
    F2: FnMut(&WlSurface, &SurfaceData, &T),
    F3: FnMut(&WlSurface, &SurfaceData, &T) -> bool,

Available on crate feature wayland_frontend only.

Access the data of a surface tree from bottom to top

You provide three closures, a “filter”, a “processor” and a “post filter”.

The first closure is initially called on a surface to determine if its children should be processed as well. It returns a TraversalAction<T> reflecting that.

The second closure is supposed to do the actual processing. The processing closure for a surface may be called after the processing closure of some of its children, depending on the stack ordering the client requested. Here the surfaces are processed in the same order as they are supposed to be drawn: from the farthest of the screen to the nearest.

The third closure is called once all the subtree of a node has been processed, and gives an opportunity for early-stopping. If it returns true the processing will continue, while if it returns false it’ll stop.

The arguments provided to the closures are, in this order:

• The surface object itself
• a mutable reference to its surface attribute data
• a mutable reference to its role data,
• a custom value that is passed in a fold-like manner, but only from the output of a parent to its children. See TraversalAction for details.

If the surface not managed by the CompositorGlobal that provided this token, this will panic (having more than one compositor is not supported).