Show/HideWayland window

Andreas Ericsson ae at
Fri Mar 16 03:32:48 PDT 2012

On 03/16/2012 05:54 AM, at wrote:
> I may destroy (Hide) and re-construct surafce (show) to achieve this
> point. But I think we may have 2 reasons to implement show/hide:
> 1. It may reduce unnecessary cost when switch frequently.

Not really, since "destroy" in this case just means that the client says
"don't paint this!". The client's request to wayland to destroy a window
really is a "hide" event. What the client does with the buffer that
contains the image painted where the window was is irrelevant to wayland.

> 2. re-construct surface may have to restore some user data. If wayland
> could do this, it could avoid application to save additional data.

Not really. Wayland paints things from images that the client (application)
handles. Though I imagine this will be done by frameworks 99.9% of the time,
that's hardly relevant. Wayland is not a key/value storage for applications
to put data in, and hidden window's can't receive events (transparent ones
can, but destroyed/hidden ones can't), so there's no data that wayland would
care about that the application can be saved from saving, so to speak.

Andreas Ericsson          at
OP5 AB                   
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

More information about the wayland-devel mailing list