Hi,<br><br>On Thursday, December 11, 2014, Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com">giuliocamuffo@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2014-12-11 4:04 GMT+02:00 Bryce Harrington <<a href="javascript:;" onclick="_e(event, 'cvml', 'bryce@osg.samsung.com')">bryce@osg.samsung.com</a>>:<br>
> +      A surface manages a rectangular grid of pixels that clients create<br>
> +      for displaying their content to the screen.  Clients don't know<br>
> +      the global position of their surfaces, and cannot access other<br>
> +      clients surfaces.</blockquote><div><br></div><div>It would be good to make the linkage to wl_buffers clear, i.e. that surfaces do not have intrinsic storage of their own.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> +      A surface has a pair of content buffers that are swapped between<br>
<br>
Uhm, a surface can actually use more than two buffers, that depends on<br>
the client only. For shm buffers, if the compositor supports it, a<br>
surface can even be single buffered without creating artifacts.</blockquote><div><br></div><div>Yeah, that was my first thought on reading this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> +      the client and the compositor.  Once the client has finished<br>
> +      writing pixels, it 'commits' the buffer; this permits the<br>
> +      compositor to access the buffer and read the pixels.  When the<br>
> +      compositor is finished with a buffer, it releases it back to the<br>
> +      client.  This way, the client can begin writing the next buffer<br>
> +      while the compositor is processing the current one.<br>
</blockquote><div><br></div><div>It might also be nice to clarify that this can happen at any time: instantly (i.e. copying into a shadow buffer, such as SHM buffers on GL/RPi renderers), immediately on the next attach/commit (i.e. a renderer with no scanout promotion that does a blit for final presentation, such as GL buffers on GL renderer), or sometime later (buffer promoted directly to scanout, such as a DRM/atomic backend). But ideally without reference to those specific cases, as they're really just implementation details that can change.</div><div><br></div><div>Thanks a lot for doing this! Are you planning to do others?</div><div><br></div><div>Cheers,</div><div>Daniel</div>