<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 19 February 2013 10:17, Ander Conselvan de Oliveira <span dir="ltr"><<a href="mailto:conselvan2@gmail.com" target="_blank">conselvan2@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="im"><span style="color:rgb(34,34,34)">That's a tricky one. I agree that the timestamp of a frame callback does not represent the moment the last attached buffer reached the screen. But the timestamp is that of the latest completed flip.</span><br>
</div>
<br>
The protocol description for wl_surface::frame reads: "Request notification when the next frame is displayed". It does not define if the next frame need to contain any newly attached buffer. So except for the case of idle_repaint(), one could consider the current implementation correct.</blockquote>
<div><br></div><div style>If we want to get all smug and tell the client that 'next frame' actually has no meaning wrt request ordering, we might as well just send the frame callback instantly.  Seriously, either we should reword the spec, or find a way to change it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If that is what we want, that's a different story. But because of our latency, it seems providing accurate timestamps could hinder our ability to drive repaint using frame callbacks.<br>
</blockquote><div><br></div><div style>The problem (which, to be fair, has only occurred to me reading this mail) is that we're trying to solve two conflicting usecases: having a simple way to drive animation timing loops, vs. having accurate timing information for media players.  Knowing when the frame actually hit the screen (as opposed to when the compositor processed the request, before it even thought about beginning to repaint or subsequently flip) is pretty crucial for media players.  I think this is something we need to serve if at all possible, but it would probably require both triple-buffering and much smarter clients to hit full framerate.</div>
<div style><br></div><div style>Perhaps what we need is to reword frame to make it clear that it's only when the compositor's started _processing_ the frame, and add a second (well, third, if you count wl_buffer::release) frame event which lets it know when the buffer has actually been _presented_.</div>
<div style><br></div><div style>Thoughts?</div><div style><br></div><div style>Cheers,</div><div style>Daniel</div></div></div></div>