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

[Jason Ekstrand]

On Mon, Apr 29, 2013 at 2: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?
>

I'm not really seeing a race.  If you want to keep everything syncronized,
you have to syncronize it anyway.  Specifically, the children are going to
wait on the parent commit in some way before they redraw, so they can wait
for the parent to call cache_child_commits again.  The case I know of that
gets strange is where you have a parent P and, say, three children C1, C2,
and D where C1 and C2 are synchronized but D is not.  My suggestion doesn't
handle that case quite as well, but you can still do it as follows:

C1.cache_child_commits
draw(C1)
C2.cache_child_commits
draw(C2)
P.cache_child_commits
C1.commit
C2.commit
P.commit

I realize that this is a bit more complicated in that case.

We could just rename set_sync and set_desync to something more obvious,
> any suggestions?
>

I don't know.  Maybe set_sync and unset_sync or set_desync is the best way
to go.  The "cache children" concept makes more sense in my brain but my
brain can be a strange place some days.


>
>
> Thanks,
> pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130429/ef09e2ec/attachment.html>