Show/HideWayland window
Andreas Ericsson
ae at op5.se
Fri Mar 16 03:32:48 PDT 2012
On 03/16/2012 05:54 AM, yan.wang at linux.intel.com 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 andreas.ericsson at op5.se
OP5 AB www.op5.se
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