On Sat, 27 Apr 2013 15:18:29 -0500 Jason Ekstrand <[email protected]> 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? Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
