Sub-surface protocol

[Pekka Paalanen]

Hi John,


On Thu, 13 Dec 2012 14:51:17 +0100
John Kåre Alsaker <john.kare.alsaker at gmail.com> wrote:

> Here is my "subsurface" proposal. I don't like video sinks (or other
> things) running on an independent framerate. I don't want to maintain
> more state in the compositor side for them or have increased
> complexity in the protocol. They are inefficient and can be solved by
> a number of other ways. In those cases you can change the API, clients
> can buffer the video sink state for themselves (which you should be
> able to do if you're porting to Wayland), or the worst case, render
> them off-screen and let the client draw them as they please.

Ok, that is the reason you chose that sub-surface commits are no-op,
right?

> My proposal uses a wl_surface_group which is a group of wl_surfaces
> with a defined Z-order and positions relative to the main surface. It
> has a concept of a main surface which is the surface which acts as the
> wl_surface_group for other APIs like wl_shell_surface. Member surfaces
> cannot have a wl_shell_surface. main_surface is created in the
> create_surface_group request so it can have a different implementation
> (which probably won't happen in Weston).

My thoughts exactly, just slightly different objects in the protocol.
I'm hooking the sub-surface role into the weston_surface::configure
pointer, which automatically excludes all other roles for a surface.

> <interface name="wl_surface_group_factory" version="1">
> 	<request name="create_surface_group">
> 		<description summary="remove a surface from the group">
> 			This creates a new wl_surface_group with 'main_surface' as the main surface.
> 			The commit for the main surface commits all pending place_above,
> place_below, set_position,
> 			remove requests and pending state for all member surfaces. Doing
> commit on member surface will be a no-op.
> 			Moving the main surface will move all member surfaces too.
> 			Only the main surface can have an associated wl_shell_surface or
> other shell interfaces.
> 		</description>
> 		<arg name="new_surface_group" type="new_id" interface="wl_surface_group"/>
> 		<arg name="main_surface" type="new_id" interface="wl_surface"/>
> 	</request>
> </interface>
> 
> <interface name="wl_surface_group" version="1">
> 	<request name="destroy" type="destructor">
> 	</request>
> 
> 	<request name="remove">
> 		<description summary="remove a surface from the group">
> 			This removes a surface from the group. The main surface cannot be removed.
> 		</description>
> 		<arg name="surface" type="object" interface="wl_surface"/>
> 	</request>
> 
> 	<request name="set_position">
> 		<description summary="remove a surface from the group">
> 			This sets the position of a member surface relative to the main surface.
> 		</description>
> 		<arg name="surface" type="object" interface="wl_surface"/>
> 		<arg name="x" type="int"/>
> 		<arg name="y" type="int"/>
> 	</request>
> 
> 	<request name="place_above">
> 		<description summary="place a surface above another">
> 			This places 'surface' right above 'relative_to_surface'.
> 			If 'surface' isn't a member of this group, it will become a member.
> 			It is an error to add a surface belonging to another wl_surface_group.
> 		</description>
> 		<arg name="surface" type="object" interface="wl_surface"/>
> 		<arg name="relative_to_surface" type="object" interface="wl_surface"/>
> 	</request>
> 
> 	<request name="place_below">
> 		<description summary="place a surface below another">
> 			This places 'surface' right below 'relative_to_surface'.
> 			If 'surface' isn't a member of this group, it will become a member.
> 			It is an error to add a surface belonging to another wl_surface_group.
> 		</description>
> 		<arg name="surface" type="object" interface="wl_surface"/>
> 		<arg name="relative_to_surface" type="object" interface="wl_surface"/>
> 	</request>
> </interface>

This looks very much like what I am working with, with the exceptions:
- instead of wl_surface_group, each sub-surface has a wl_subsurface
  object, whose creation defines also the parent.
- the requests you have in wl_surface_group, I have in wl_subsurface,
  practically identical otherwise
- what you call main surface, I call parent

The description in your create_surface_group is pretty much the same
semantics I am implementing, with the difference in sub-surface commit
behaviour.

I have my version in a WIP branch:
http://cgit.collabora.com/git/user/pq/wayland.git/tree/protocol/wayland.xml?h=subsurface-wip#n1358
There are still some semantics to be explained more. It's a simple
addition to protocol, but the semantics and implementation are
non-trivial the least.

> I see that in weston the shell is very glad in inspecting geometry. We
> also have to alpha property per-surface instead of per
> wl_shell_surface. For fading windows we may want to compose the
> wl_surface_group into a single image.

I don't think we want to do intermediate composites, unless we can put
it into a plane. Otherwise it's just extra data movement. It seems to
be very easy to hook a compound window into the input and repaint
procedures by just adding all the wl_surfaces into the big surface
list created during weston_output_repaint(). I don't have to revamp
either input nor repaint code. I actually got that part working right
now.

For alpha, we can easily enough change the surface alpha for all...
wait, that would not really work right. We'd have to manipulate the
repaint regions, too. Maybe that's not even enough, oh well.

As for shell, we probably need a helper for providing the compound
window size.


Thanks,
pq