[PATCH weston v3 01/13] protocol: add sub-surfaces

[David Herrmann]

Hi

On Mon, Apr 29, 2013 at 9:11 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Sat, 27 Apr 2013 15:18:29 -0500
> Jason Ekstrand <jason at jlekstrand.net> wrote:
>
>> Sorry to spam the list, but I had another idea kicking around my head
>> this weekend that I thought was worth sharing.  Please note that I
>> don't think this is a stopper.  I just think it's worth throwing out
>> there and seeing if others think it's useful.
>>
>> I don't think there are any major holes in commit behavior in the
>> current protocol.  That said, there seems to be some confusion on
>> commit modes and how they interact with the tree of subalgebras that
>> I think is justified. I think this could be (somewhat) solved by the
>> following simplification. We could replace the explicit commit modes
>> that then impose commit modes on the children with a single
>> cache_child_commits request which would begin caching the data for
>> child surfaces until commit is called on the same surface.  In terms
>> of the current mechanism, cache_child_commits would set synced and
>> commit would automatically unset synced.
>>
>> The advantage I see to this approach is that it makes it more clear
>> that it affects the entire tree and how it does so.  Also, it
>> requires the client to explicitly put any synced commits between a
>> cached_child_commits and commit which I personally think is cleaner.
>> The disadvantage is that it is a little less flexible in that you
>> can't cache single children.  However, if you can have "dummy
>> nodes" (see previous ML posts), this shouldn't be a problem in most
>> cases.
>>
>> Again, I don't think this is a show-stopper and I think the protocol
>> as-is is ok.  I just thought it might be worth mentioning.
>> --Jason Ekstrand
>
> Hi Jason,
>
> isn't this racy? If you want to keep all children always synchronized,
> don't you have to re-send cache_child_commits every time you commit the
> main surface, and hope that the child components to do not manage to
> send a new commit between your commit and cache_child_commits?
>
> We could just rename set_sync and set_desync to something more obvious,
> any suggestions?

So the reason for this proposal is to make the protocol more obvious
and easier to understand? Imo, that's a reason to improve
documentation, not to change the protocol. And honestly, I don't think
the design is hard to understand. All my concerns were about
documentation, not about the design. Or what exactly is the "hard to
understand" part of the current design?

Cheers
David