<div dir="ltr">On Thu, Jun 13, 2013 at 2:42 PM, 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">
Libwayland does not synchronize, it only protects the queues for the<br>
very short moment each time they are modified. It does not cause one<br>
application component to stall and wait for another component to wake<br>
up, realize there is something to do, and then do it. Libwayland also<br>
does not force other threads to wake up, if one thread wants to do<br>
something. And with the fd locking patches for libwayland-client, that<br>
will actually be true all the way.<br></blockquote><div>The sort of synchronization required is exactly the same as what is needed by libwayland-client. It needs to send some bytes to the compositor without being interrupted by other threads. My point here holds unless libwayland-client gets a communication channel per thread (instead of per wl_display).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is very much about performance, and also about avoiding the need for<br>
component APIs to have a hook for "I want to update my output now"<br>
which crosses thread boundaries.<br></blockquote><div>I'd say adding a mutex (or reusing one in libwayland-client) is probably faster than doing the additional work required by the compositor in the current implementation, both being insignificant.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> If you absolutely can't tolerate any synchronization in that case<br>
> (which we won't be able to avoid at the libwayland level anyway) a<br>
> simpler solution is to let wl_surface.commit atomically commit itself<br>
> and all children recursively. You then commit to two separate<br>
<br>
</div>Committing children is a no-go, unless you have a mechanism to<br>
guarantee a consistent snapshot of the child surface state.<br></blockquote><div>Each thread gets it's own wl_surface and possible children. It's up to each thread to make sure their tree of surfaces is consistent. Each thread would call commit on their wl_surfaces. You'd only call commit on the top-level surface when resizing.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> wl_surfaces in the main and the component thread both of which have<br>
> the top-level wl_surface as a parent. However to do this we need a<br>
> way to map a surface without a buffer (or use a transparent one...)<br>
> since the top-level wl_surface can't have content. It also won't<br>
<br>
</div>Funny how no toolkit developer has brought that "problem" up yet.<br></blockquote><div>I'm not quite sure which problem you refer to here. The problem of using a mapped wl_surface with no content to group up wl_surfaces belonging to separate threads as is rather unique to my solution.</div>
<div><br></div><div>The problem of using a mapped wl_surface with no content and an input region of non-infinite size is a more general one, which I suspect you're referring to. I assume you have solved that by clipping the input region to the extends of the surface and children and moving the content of one of the subsurfaces into the parent. That solution won't work for my proposal since it would require synchronization when committing the parent. I instead have to pick between using a 1x1 buffer (ugh), explicit map/unmap requests (ugh) and introducing a wl_empty_buffer (meh). I prefer the wl_empty_buffer option. It also allows me to have input region to be clipped to the surface content without including children, although I don't see any reason to do that. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> allow eglSwapBuffers to work in subsurfaces (if we could even<br>
> guarantee that it's non-blocking), but that will be rectified by the<br>
> wl_egl_window_* additions we discussed.<br>
<br>
</div>You have pretty high hopes it would go through... shall see, when you<br>
have an implementation.<br></blockquote><div>It's too nice and useful to not go through. It's very easy to implement in the current form. The question is if we want something more advanced...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
<br>
- pq<br>
</blockquote><br></div>