<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 29, 2013 at 2:11 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sat, 27 Apr 2013 15:18:29 -0500<br>
Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
<br>
> Sorry to spam the list, but I had another idea kicking around my head<br>
> this weekend that I thought was worth sharing.  Please note that I<br>
> don't think this is a stopper.  I just think it's worth throwing out<br>
> there and seeing if others think it's useful.<br>
><br>
> I don't think there are any major holes in commit behavior in the<br>
> current protocol.  That said, there seems to be some confusion on<br>
> commit modes and how they interact with the tree of subalgebras that<br>
> I think is justified. I think this could be (somewhat) solved by the<br>
> following simplification. We could replace the explicit commit modes<br>
> that then impose commit modes on the children with a single<br>
> cache_child_commits request which would begin caching the data for<br>
> child surfaces until commit is called on the same surface.  In terms<br>
> of the current mechanism, cache_child_commits would set synced and<br>
> commit would automatically unset synced.<br>
><br>
> The advantage I see to this approach is that it makes it more clear<br>
> that it affects the entire tree and how it does so.  Also, it<br>
> requires the client to explicitly put any synced commits between a<br>
> cached_child_commits and commit which I personally think is cleaner.<br>
> The disadvantage is that it is a little less flexible in that you<br>
> can't cache single children.  However, if you can have "dummy<br>
> nodes" (see previous ML posts), this shouldn't be a problem in most<br>
> cases.<br>
><br>
> Again, I don't think this is a show-stopper and I think the protocol<br>
> as-is is ok.  I just thought it might be worth mentioning.<br>
> --Jason Ekstrand<br>
<br>
</div></div>Hi Jason,<br>
<br>
isn't this racy? If you want to keep all children always synchronized,<br>
don't you have to re-send cache_child_commits every time you commit the<br>
main surface, and hope that the child components to do not manage to<br>
send a new commit between your commit and cache_child_commits?<br></blockquote><div><br></div><div>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:<br>
<br></div><div>C1.cache_child_commits<br></div><div>draw(C1)<br></div><div>C2.cache_child_commits<br></div><div>draw(C2)<br></div><div>P.cache_child_commits<br>C1.commit<br></div><div>C2.commit<br></div><div>P.commit<br><br>
</div><div>I realize that this is a bit more complicated in that case.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We could just rename set_sync and set_desync to something more obvious,<br>
any suggestions?<br></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div></div>