[RFC] Sub-surface protocol and implementation v1

Pekka Paalanen ppaalanen at gmail.com
Fri Dec 21 03:56:48 PST 2012

Hi all,

we started a discussion about sub-surfaces in Wayland in [1].
Based on that, and with heavy limiting of scope, I present my first
sub-surface draft:


The following changes since commit 812bd4dd0fb20161aaf07029fbd6146d530b9932:

  client: remove two unused function pointer typedefs (2012-12-12 11:04:53 -0500)

are available in the git repository at:
  git://git.collabora.co.uk/git/user/pq/wayland.git subsurface-v1

Pekka Paalanen (1):
      protocol: add sub-surfaces

 protocol/wayland.xml |  122 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 122 insertions(+), 0 deletions(-)

The following changes since commit e565b405695d2dbcfbf0fd228fe8885ff522ae84:

  tests: Pass --backend so the test suite runs with the right modules (2012-12-14 16:34:00 -0500)

are available in the git repository at:
  git://git.collabora.co.uk/git/user/pq/weston.git subsurface-v1

Pekka Paalanen (11):
      tests: make signal other than ABRT a hard failure
      shell: remove remnants of screensaver surface list
  surface transform inheritance:
      compositor: update weston_surface:transform.matrix always
      compositor: introduce weston_surface_geometry_dirty()
      compositor: put weston_matrix_pointer into transformation_list
      compositor: popup inherits surface transformation
  sub-surface work:
      compositor: introduce sub-surfaces
      tests: add sub-surface protocol tests
      compositor: add sub-surfaces to repaint list
      shell: keyboard focus with sub-surfaces
      clients: add a demo for sub-surfaces

 clients/.gitignore            |    1 +
 clients/Makefile.am           |    4 +
 clients/subsurfaces.c         |  239 ++++++++++++++++++++
 src/compositor.c              |  489 ++++++++++++++++++++++++++++++++++++++---
 src/compositor.h              |   85 ++++++--
 src/shell.c                   |  121 ++++++-----
 src/util.c                    |    9 +-
 src/xwayland/window-manager.c |    4 +-
 tests/.gitignore              |    2 +
 tests/Makefile.am             |    4 +
 tests/subsurface-test.c       |  306 ++++++++++++++++++++++++++
 tests/weston-test-runner.c    |    6 +-
 tests/weston-test.c           |    2 +-
 13 files changed, 1165 insertions(+), 107 deletions(-)
 create mode 100644 clients/subsurfaces.c
 create mode 100644 tests/subsurface-test.c

I will reply to this email with the sub-surface patches, but leave out
the preparatory work that I have already posted earlier.

I chose to leave all clipping and scaling outside the scope of this
work for now, we should discuss those later.

This proposal allows sub-surfaces to form a single window, that may be
updated in unison, honouring the every frame is perfect -principle. The
implementation does not yet fully achieve that, though. More details are
in the commit messages and the protocol definition.

I'll quote my earlier email [2], explaining the base for the design:
> Conceptually I see it like this: zero or more sub-surfaces with one main
> surface forms a window. A window is the entity managed at window
> manager level, and therefore a window is what can be a top-level
> window, tooltip, menu, etc.
> On the protocol level, these concepts are built on the wl_surface
> object, which can form a part of a window (by being a sub-surface), or
> the base object of a window (the main surface, or "parent"). The base
> object can then be associated with meanings like top-level and tooltip
> in the shell level of the protocol.

Even though the implementation is a little lacking, it is already
usable. The 'subsurfaces' client just shows a red rectangle [3], but
could be extended to draw something more interesting. Sub-surfaces are
drawn and positioned properly, so people could already start
experimenting with them. Committing is subject to change, but otherwise
I don't expect changes to be required in clients written against the v1

This would be a nice moment to try and write a video player with
decorations _and_ YUV video content, or a GL application with software
rendered decorations. You might even try whether stitching decorations
from 4 sub-surfaces would work. These should offer us more insight on
how sub-surfaces should be defined. :-)

There are still many open questions, ranging from implementation
details I noted in code comments and commit messages, to heavy protocol
additions like clipping. Some of the open questions are:
- how should commits work in parent vs. sub-surfaces?
- do we allow nested sub-surfaces?
- do we want a completely orthogonal interface for clipping and scaling,
  or should it be limited to sub-surfaces?
- should we forbid reparenting?
- should sub-surface role be revertible, instead of permanent?
- should a sub-surface be restricted to its parent's area?
Personally, I have to postpone all that till January or later.

Happy mid-winter and joyful New Year,

[1] http://lists.freedesktop.org/archives/wayland-devel/2012-December/006623.html
[2] http://lists.freedesktop.org/archives/wayland-devel/2012-December/006837.html
[3] http://people.collabora.com/~pq/subsurface-1.png

More information about the wayland-devel mailing list