<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>Hi，Jonas：</div><div> </div><div>I try to set invisible on current surface with “attach(0, 0, 0)”, but as said in website, attach NULL buffer will cause freeze issue, so I want to use another way to make invisible effort.</div> <div>I find this function “set_buffer_scale”, but how to use it?</div><div>I have done experiment to use wl_surface::set_buffer_scale(0), the surface can be invisible, but how recover it to visible? I tried wl_surface::set_buffer_scale(1), but nothing happens, the surface is still invisible.</div> <h4><a name="protocol-spec-wl_surface-request-set_buf"></a>wl_surface::set_buffer_scale - sets the buffer scaling factor<o:p></o:p></h4> scale<o:p></o:p> int - positive scale for interpreting buffer contents<o:p></o:p> This request sets an optional scaling factor on how the compositor interprets the contents of the buffer attached to the window.<o:p></o:p> Buffer scale is double-buffered state, see wl_surface.commit.<o:p></o:p> A newly created surface has its buffer scale set to 1.<o:p></o:p> wl_surface.set_buffer_scale changes the pending buffer scale. wl_surface.commit copies the pending buffer scale to the current one. Otherwise, the pending and current values are never changed.<o:p></o:p> The purpose of this request is to allow clients to supply higher resolution buffer data for use on high resolution outputs. It is intended that you pick the same buffer scale as the scale of the output that the surface is displayed on. This means the compositor can avoid scaling when rendering the surface on that output.<o:p></o:p> Note that if the scale is larger than 1, then you have to attach a buffer that is larger (by a factor of scale in each dimension) than the desired surface size.<o:p></o:p> If scale is not positive the invalid_scale protocol error is raised. <o:p></o:p> <pre> At 2016-12-23 11:25:05, "Jonas Ådahl" <jadahl@gmail.com> wrote: >On Fri, Dec 23, 2016 at 09:52:45AM +0800, Anthenony wrote: >> Hi, All: >> >> >> As far as I know there is no interface to hide or show the client. I want to make sure whether other method is feasible. >> For example, I move the client out of the screen. >> >> Hide: >> attach(m_wl_sufface, 1000, 1000); >> commit(); >> >> Show: >> attach(m_wl_sufface, 0, 0); >> commit(); >> >> >> Anyway, is there any other methods? > >Attaching with an offset should not be used to hide a surface. It's a >total abuse of those parameters and will definitely not work reliably. I >wouldn't be surprised if compositors will blatantly terminate clients >abusing it in such ways, since it would make no sense from the point of >view of the way those parameters were intended to be used. > >The proper way depends on the role the surface has. For example if it's >a pointer cursor surface, and you want to hide the cursor, you set the >pointer cursor to a NULL surface. If it's a shell surface (xdg_toplevel >or a toplevel wl_shell_surface) you unmap it; how unmapping is done >depends on the protocol defining the role. For example if it's a >xdg_toplevel, to unmap the surface you destroy the xdg_toplevel and >xdg_surface objects. For wl_shell_surface clients, it's similar; destroy >the wl_shell_surface object to unmap the surface. > >For other roles, it's up to the role to define how to hide/unmap the >corresponding surface view. > > >Jonas > >> >> >> >> >> Best regards, >> Anthenony > </pre></div>