From 419e2bae92a89eb1f69fb127078f974965214bc2 Mon Sep 17 00:00:00 2001 From: Pekka Paalanen Date: Fri, 17 May 2013 16:46:03 +0300 Subject: [PATCH] protocol: improve sub-surface spec wording Mention, that sub-surfaces are not clipped to the parent. Be more accurate on surface commit vs. apply state. Mention the initial stacking order. Signed-off-by: Pekka Paalanen --- protocol/subsurface.xml | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/protocol/subsurface.xml b/protocol/subsurface.xml index 4407fd72..9e4a658d 100644 --- a/protocol/subsurface.xml +++ b/protocol/subsurface.xml @@ -85,7 +85,10 @@ An additional interface to a wl_surface object, which has been - made a sub-surface. A sub-surface has one parent surface. + made a sub-surface. A sub-surface has one parent surface. A + sub-surface's size and position are not limited to that of the parent. + Particularly, a sub-surface is not automatically clipped to its + parent's area. A sub-surface becomes mapped, when a non-NULL wl_buffer is applied and the parent surface is mapped. The order of which one happens @@ -97,8 +100,8 @@ depends on the sub-surface's mode. The possible modes are synchronized and desynchronized, see methods wl_subsurface.set_sync and wl_subsurface.set_desync. Synchronized - mode caches wl_surface state to be applied on the next parent - surface's commit, and desynchronized mode applies the pending + mode caches the wl_surface state to be applied when the parent's + state gets applied, and desynchronized mode applies the pending wl_surface state directly. A sub-surface is initially in the synchronized mode. @@ -111,15 +114,15 @@ wl_surface state is applied, regardless of the sub-surface's mode. As the exception, set_sync and set_desync are effective immediately. - The main surface can thought to be always in desynchronized mode, + The main surface can be thought to be always in desynchronized mode, since it does not have a parent in the sub-surfaces sense. Even if a sub-surface is in desynchronized mode, it will behave as in synchronized mode, if its parent surface behaves as in synchronized mode. This rule is applied recursively throughout the tree of surfaces. This means, that one can set a sub-surface into - synchronized mode, and then assume that all its child sub-surfaces - are synchronized, too, without explicitly setting them. + synchronized mode, and then assume that all its child and grand-child + sub-surfaces are synchronized, too, without explicitly setting them. If the wl_surface associated with the wl_subsurface is destroyed, the wl_subsurface object becomes inert. Note, that destroying either object @@ -151,7 +154,9 @@ This schedules a sub-surface position change. The sub-surface will be moved so, that its origin (top-left - corner pixel) will be at the location x, y of the parent surface. + corner pixel) will be at the location x, y of the parent surface + coordinate system. The coordinates are not restricted to the parent + surface area. Negative values are allowed. The next wl_surface.commit on the parent surface will reset the sub-surface's position to the scheduled coordinates. @@ -174,6 +179,9 @@ The z-order is double-buffered state, and will be applied on the next commit of the parent surface. See wl_surface.commit and wl_subcompositor.get_subsurface. + + A new sub-surface is initially added as the top-most in the stack + of its siblings and parent.