[RFC Weston 00/10] Sub-surfaces v2

Daniel Stone daniel at fooishbar.org
Wed Mar 6 12:58:58 PST 2013


Hi,

On 22 February 2013 07:07, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> The biggest improvement over v1 is that we have some thought-out
> commit behaviours. It is possible to resize a window so that all
> surfaces stay in sync on screen, and it is also possible to have
> sub-surfaces running on their own (i.e. without commit the
> parent surface, too).
>

One thing I noticed is that a subsurface is defined to be mapped as soon as
it has a valid buffer attached, and its parent is mapped.  Presumably this
means that if:
  - the parent window is already mapped
  - the child is brought into being, and attaches a buffer as part of this
  - a subsurface is created for the child

then the subsurface will be mapped before the parent has had a chance to
either repaint itself, or even call set_position.  So maybe that's
something we need to look at for the embed (as opposed to decoration) case,
either with an explicit map request, or just adding 'and set_position has
been called' to the list of map conditions.

It's also undefined what the commit_mode is for a new wl_subsurface object
- and having the commit mode initially set to parent-cached might be enough
to get around the map issue.  Also, if the commit mode is parent-cached,
changes are made which are put into the cache, and commit mode is then
changed to immediate before the parent is committed, will the cached
changes be committed? It's about the only semantics I can think of which
really make sense for this.

This might all be fixed in the implementation, but it's not clear from the
spec.

- Input events still very much unexplored. The demo just punts
>   them.
>

At the very least, we're going to need flags on enter/leave events to note
when the pointer left towards a subsurface.

Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130306/e708e4fb/attachment.html>


More information about the wayland-devel mailing list