Hi,<br><br>On Friday, December 12, 2014, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think talking about a surface having multiple buffers is misleading.<br>
<br>
A wl_surface only knows about one buffer after commit: the last buffer attached to it. The wording being proposed here makes it sound like the surface keeps track of the previous buffer and expects or requires it to be used in the next attach.</blockquote><div><br></div><div>This is technically true, but I think helpful for the introduction.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the problem with the docs right now is that a lot of wl_surface requests say "foo is double-buffered state, see wl_surface.commit". The word double-buffered unfortunately immediately makes people think only about pixel buffers, even though in fact it is other data that is being double-buffered.<br>
<br>
I would avoid the use of the term "double buffered". Possible alternative: "The change does not happen until the next wl_surface.commit." All current talk about double-buffering in commit should use words like "deferred" or "pending" instead.<br>
</blockquote><div><br></div><div>Or 'latched'. Either way, I think 'double-buffered' referring to the surface state updated on commit has to go.</div><div><br></div><div>Cheers,</div><div>Danirl<span></span> </div>