On Mon, Apr 29, 2013 at 2:11 AM, Pekka Paalanen <[email protected]> wrote:
> 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? > 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 >
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
