<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 22 February 2013 07:07, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The biggest improvement over v1 is that we have some thought-out<br>

commit behaviours. It is possible to resize a window so that all<br>
surfaces stay in sync on screen, and it is also possible to have<br>
sub-surfaces running on their own (i.e. without commit the<br>
parent surface, too).<br></blockquote><div><br></div><div style>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:</div>
<div style>  - the parent window is already mapped</div><div style>  - the child is brought into being, and attaches a buffer as part of this</div><div style>  - a subsurface is created for the child</div><div style><br></div>
<div style>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.</div>
<div style><br></div><div style>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. </div>
<div style><br></div><div style>This might all be fixed in the implementation, but it's not clear from the spec.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Input events still very much unexplored. The demo just punts<br>
  them.<br></blockquote><div><br></div><div style>At the very least, we're going to need flags on enter/leave events to note when the pointer left towards a subsurface.</div><div><br></div><div><div>Cheers,</div><div>
Daniel</div></div></div></div></div>